WebPagetest 工作原理的关键在于它能够拦截任意函数调用并在将请求或响应传递到原始实现（或选择根本不传递）之前检查或更改请求或响应。幸运的是，其他人完成了大部分繁重的工作，并提供了一个很好的开源库（http://newgre.net/ncodehook），它可以为您处理细节，但它基本上是这样工作的：

The key to how WebPagetest works is its ability to intercept arbitrary function calls and inspect or alter the request or response before passing it on to the original implementation (or choosing not to pass it on at all). Luckily someone else did most of the heavy lifting and provided a nice open source library (http://newgre.net/ncodehook) that can take care of the details for you but it basically works like this:

这是非常棘手的事情，如果您不非常小心，事情往往会变得 非常错误，但是通过明确定义的函数（如所有 Windows API），您几乎可以拦截您想要的任何内容。

It’s pretty hairy stuff and things tend to go very wrong if you aren’t extremely careful, but with well-defined functions (like all of the Windows APIs), you can pretty much intercept anything you’d like.

一个问题是，您只能将调用重定向到与原始函数在同一进程中运行的代码，如果您编写了代码，这很好，但如果您试图监视您无法控制的软件，则没有多大帮助这导致我们……

One catch is that you can only redirect calls to code running in the same process as the original function, which is fine if you wrote the code but doesn’t help a lot if you are trying to spy on software that you don’t control which leads us to…

对我来说幸运的是，Windows 提供了多种将任意代码注入进程的方法。这里对几种不同的技术进行了很好的概述：http://www.codeproject.com/KB/threads/winspy.aspx，实际上有更多的方法可以做到这一点，但它涵盖了基础知识。有些技术将代码插入到每个进程中，但我希望更有针对性，只检测我们感兴趣的特定浏览器实例，因此经过一系列实验（和可怕的失败）后，我最终使用了 CreateRemoteThread /LoadLibrary 技术本质上可以让您强制任何进程加载任意 dll 并在其中执行代码（假设您拥有必要的权限）。

Lucky for me, Windows provides several ways to inject arbitrary code into processes. There is a good overview of several different techniques here: http://www.codeproject.com/KB/threads/winspy.aspx, and there are actually more ways to do it than that but it covers the basics. Some of the techniques insert your code into every process but I wanted to be a lot more targeted and just instrument the specific browser instances that we are interested in, so after a bunch of experimentation (and horrible failures), I ended up using the CreateRemoteThread/LoadLibrary technique which essentially lets you force any process to load an arbitrary dll and execute code in it (assuming you have the necessary rights).

既然我们可以拦截任意函数调用，那么只需识别“有趣”的函数，最好是所有浏览器都使用的函数，这样您就可以重用尽可能多的代码。在WebPagetest中，我们拦截所有与解析主机名、连接套接字以及读取或写入数据有关的Winsock调用（图1-2）。

Now that we can intercept arbitrary function calls, it just becomes a matter of identifying the “interesting” functions, preferably ones that are used by all the browsers so you can reuse as much code as possible. In WebPagetest, we intercept all the Winsock calls that have to do with resolving host names, connecting sockets, and reading or writing data (Figure 1-2).

图 1-2。浏览器架构

Figure 1-2. Browser architecture

这使我们能够通过浏览器访问所有网络访问，并且我们本质上只是跟踪浏览器正在做什么。除了必须解码原始字节流之外，它非常简单，并且为我们提供了一种在所有浏览器上进行测量的一致方法。SSL 确实增加了一些麻烦，因此我们还拦截对浏览器使用的各种 SSL 库的调用，以便我们可以看到数据的未加密版本。这对于 Chrome 来说有点困难，因为该库被编译到 Chrome 代码本身中，但幸运的是，它们为每个构建提供了调试符号，因此我们仍然可以在内存中找到代码。

This gives us access to all the network access from the browser and we essentially just keep track of what the browsers are doing. Other than having to decode the raw byte streams, it is pretty straightforward and gives us a consistent way to do the measurements across all browsers. SSL does add a bit of a wrinkle so we also intercept calls to the various SSL libraries that the browsers use in order that we can see the unencrypted version of the data. This is a little more difficult for Chrome since the library is compiled into the Chrome code itself, but luckily they make debug symbols available for every build so we can still find the code in memory.

使用相同的技术来拦截来自浏览器的绘图调用，以便我们可以知道它何时绘制到屏幕上（用于开始渲染测量）。

The same technique is used to intercept drawing calls from the browser so we can tell when it paints to the screen (for the start render measurement).

由于 WebPagetest 采用 BSD 许可证，欢迎您出于您想要的任何目的重复使用任何代码。该项目位于 Google Code 上：( http://code.google.com/p/webpagetest/ )，一些更有趣的文件是：

Since WebPagetest is under a BSD license you are welcome to reuse any of the code for whatever purposes you’d like. The project lives on Google Code here: (http://code.google.com/p/webpagetest/) and some of the more interesting files are:

幸运的是，浏览器开始以标准方式公开更多有趣的信息，并且随着 W3C 资源计时规范 ( http://w3c-test.org/webperf/specs/ResourceTiming/ ) 的进步，您将能够访问大量此类信息通过 JavaScript 直接从浏览器获取信息（甚至来自您的最终用户！）。

Luckily, browsers are starting to expose more interesting information in standard ways and as the W3C Resource Timing spec (http://w3c-test.org/webperf/specs/ResourceTiming/) advances, you will be able to access a lot of this information directly from the browser through JavaScript (even from your end users!).

不久前，我创建并分享了一个简单的基准测试，用于测量从localStorage对象属性中读取值与从对象属性中读取值的情况。其他几个人调整了基准以获得更可靠的版本（http://jsperf.com/localstorage-vs-objects/10）。最终结果：在每个浏览器中读取数据比从对象属性读取相同数据localStorage要慢几个数量级。具体慢了多少？看一下图 2-1中的图表（数字越高越好）。

Not too long ago, I created and shared a simple benchmark that measured reading a value from localStorage against reading a value from an object property. Several others tweaked the benchmark to arrive at a more reliable version (http://jsperf.com/localstorage-vs-objects/10). The end result: reading from localStorage is orders of magnitude slower in every browser than reading the same data from an object property. Exactly how much slower? Take a look at the chart on Figure 2-1 (higher numbers are better).

图 2-1。基准测试结果

Figure 2-1. Benchmark results

看完此图表后，您可能会感到困惑，因为似乎localStorage没有表示读取。事实上，它是有表现的，只是你看不到它，因为 数字太低了，用这个比例甚至看不到。除了 Safari 5 能够localStorage实际显示读数之外，其他浏览器之间的差异都非常大，以至于在这张图表上无法看到。当我调整 Y 轴值时，您现在可以看到测量值如何跨浏览器叠加：

You may be confused after looking at this chart because it appears that reading from localStorage isn’t represented. In fact, it is represented, you just can’t see it because the numbers are so low as to not even be visible with this scale. With the exception of Safari 5, whose localStorage readings actually show up, every other browser has such a large difference that there’s no way to see it on this chart. When I adjust the Y-axis values, you can now see how the measurements stack up across browsers:

图 2-2。缩放结果

Figure 2-2. Scaled results

通过更改 Y 轴的比例，您现在可以看到localStorage与对象属性读取的真实比较（图 2-2）。但尽管如此，两者之间的差异仍然如此之大，以至于近乎滑稽。为什么？

By changing the scale of the Y-axis, you’re now able to see a true comparison of localStorage versus object property reads (Figure 2-2). But still, the difference between the two is so vast that it’s almost comical. Why?

为了在浏览器会话中保持不变，中的值localStorage将写入磁盘。这意味着当您从 读取值时localStorage，您实际上是从硬盘驱动器读取一些字节。读取和写入硬盘驱动器是昂贵的操作，尤其是与读取和写入内存相比。本质上，这正是我的基准测试所测试的：从内存（对象属性）读取值与从磁盘读取值的速度（localStorage）。

In order to persist across browser sessions, values in localStorage are written to disk. That means when you’re reading a value from localStorage, you’re actually reading some bytes from the hard drive. Reading from and writing to a hard drive are expensive operations, especially as compared to reading from and writing to memory. In essence, that’s exactly what my benchmark was testing: the speed of reading a value from memory (object property) compared to reading a value from disk (localStorage).

更有趣的是，localStorage数据是按源存储的，这意味着浏览器中的两个或多个选项卡可以localStorage同时访问相同的数据。对于需要弄清楚如何同步跨选项卡访问的浏览器实现者来说，这是一个很大的痛苦。当您尝试读取 时 localStorage，浏览器需要先停止并查看是否有任何其他选项卡正在访问同一区域。如果是这样，则必须等到访问完成才能读取该值。

Making matters more interesting is the fact that localStorage data is stored per-origin, which means that it’s possible for two or more tabs in a browser to be accessing the same localStorage data at the same time. This is a big pain for browser implementors who need to figure out how to synchronize access across tabs. When you attempt to read from localStorage, the browser needs to stop and see if any other tab is accessing the same area first. If so, it must wait until the access is finished before the value can be read.

因此，与读取相关的延迟localStorage是可变的——这在很大程度上取决于浏览器在该时间点发生的其他事情。

So the delay associated with reading from localStorage is variable—it depends a lot on what else is going on with the browser at that point in time.

考虑到读取 是有成本的localStorage，这对您使用它的方式有何影响？在得出结论之前，我运行了另一个基准测试（http://jsperf.com/localstorage-string-size）来确定从localStorage. 基准测试将四个不同大小的字符串（100 个字符、500 个字符、1,000 个字符和 2,000 个字符）保存到localStorage 然后读出。结果有点令人惊讶：在所有浏览器中，读取的数据量并不 影响读取发生的速度。

Given that there is a cost to reading from localStorage, how does that affect how you would use it? Before coming to a conclusion, I ran another benchmark (http://jsperf.com/localstorage-string-size) to determine the effect of reading different-sized pieces of data from localStorage. The benchmarks saves four different size strings, 100 characters, 500 characters, 1,000 characters, and 2,000 characters, into localStorage and then reads them out. The results were a little surprising: across all browsers, the amount of data being read did not affect how quickly the read happened.

我多次进行了测试，并恳求我的 Twitter 关注者 ( https://twitter.com/slicknet/status/139475625793699840 ) 获取更多信息。可以肯定的是，不同浏览器之间确实存在一些差异，但没有大到足以真正产生影响的程度。我的结论是：从单个密钥读取多少数据并不重要localStorage。

I ran the test multiple times and implored my Twitter followers (https://twitter.com/slicknet/status/139475625793699840) to get more information. To be certain, there were definitely a few variances across browsers, but none that were large enough that it really makes a difference. My conclusion: it doesn’t matter how much data you read from a single localStorage key.

我跟进了另一个基准（http://jsperf.com/localstorage-string-size-retrieval）来测试我的新结论，即最好尽可能少地进行读取。结果与早期基准测试相关，即在大多数浏览器中读取 100 个字符 10 次比读取 10,000 个字符一次慢 90% 左右。

I followed up with another benchmark (http://jsperf.com/localstorage-string-size-retrieval) to test my new conclusion that it’s better to do as few reads as possible. The results correlated with the earlier benchmark in that reading 100 characters 10 times was around 90% slower across most browsers than reading 10,000 characters one time.

鉴于此，读取数据的最佳策略localStorage是使用尽可能少的键来存储尽可能多的数据。由于读取 10 个字符与读取 2,000 个字符所需的时间大致相同，因此请尝试将尽可能多的数据放入单个值中。每次打电话getItem()（或从 localStorage财产中读取信息）时，您都会受到打击，因此请确保您从费用中获得最大收益。将数据（无论是变量还是对象属性）放入内存的速度越快，所有后续操作的速度就越快。

Given that, the best strategy for reading data from localStorage is to use as few keys as possible to store as much data as possible. Since it takes roughly the same amount of time to read 10 characters as it does to read 2,000 characters, try to put as much data as possible into a single value. You’re getting hit each time you call getItem() (or read from a localStorage property), so make sure that you’re getting the most out of the expense. The faster you get data into memory, either a variable or an object property, the faster all subsequent actions.

自从我第一次发表这篇文章以来，已经有很多关于localStorage性能的讨论。它始于 Mozilla 的 Chris Heilmann 的一篇博客文章，标题为“localStorage 没有简单的解决方案”。localStorage在那篇文章中，克里斯介绍了整体上存在性能问题的想法。在包括我自己在内的其他人发表了几篇后续博客文章之后，我终于能够联系到 Jonas Sicking，他是负责 localStorageFirefox 实施的工程师之一。确实，存在性能问题localStorage，但它并不像读取比简单对象上的读取时间长一点那么简单。问题的核心在于localStorage是一个同步 API，这使得浏览器在实现方面几乎没有选择。所有 localStorage数据都存储在磁盘上的文件中。这意味着为了让您能够在 JavaScript 中访问该数据，浏览器必须首先将该文件读入内存。当发生读取时，就会出现性能问题。第一次访问 时可能会发生这种情况 localStorage，但随后浏览器会在读取发生时冻结。当处理少量数据时，这可能不是什么大问题，但如果您使用了整个 5 MB 限制，则可能会产生明显的影响。localStorageFirefox 采用的另一种解决方案是在加载页面时读取数据文件。这确保了以后访问localStorage 尽可能快并且具有可预测的性能。该方法的缺点是从文件读取可能会对页面的加载时间产生不利影响。当我写这篇文章时，这个特定问题仍然没有解决方案。有些人呼吁用全新的 API 来取代，localStorage而另一些人则打算修复现有的 API。无论发生什么，很快就会在客户端数据存储领域进行更多的研究。

In the time since I first published this article, there has been a lot of discussion around localStorage performance. It began with a blog post by Mozilla's Chris Heilmann titled, “There's No Simple Solution for localStorage.” In that post, Chris introduced the idea that localStorage as a whole has performance problems. After several follow up blog posts by others, including myself, I was finally able to get in touch with Jonas Sicking, one of the engineers responsible for implementing localStorage in Firefox. Indeed, there is a performance issue with localStorage, but it's not as simple as reads taking a bit longer than reads on the simple object. The heart of the problem is that localStorage is a synchronous API, which leaves the browser with very few choices as to implementation. All localStorage data is stored in a file on disk. That means in order for you to have access to that data in JavaScript the browser must first read that file into memory. When that read occurs is the performance issue. It could occur with the first access of localStorage, but then the browser would freeze while the read happened. That may not be a big deal when dealing with a small amount of data, but if you've used the whole 5 MB limit, there could be a noticeable effect. Another solution, the one employed by Firefox, is to read the localStorage data file as a page is being loaded. This ensures that later access to localStorage is as fast as possible and has predictable performance. The downside of that approach is that the read from file could adversely affect the loading time of the page. As I'm writing this, there is still no solution to this particular problem. Some are calling for a completely new API to replace localStorage while others are intent on fixing the existing API. Regardless of what happens, there is likely to be a lot more research done in the area of client-side data storage soon.

内联所有内容最明显的问题是缓存的丢失。如果HTML保存了所有资源，并且HTML本身不可缓存，则每次都会重新下载资源。这意味着新网站上的首页加载速度可能会更快，但后续页面或回访者的页面加载速度会较慢。

The most obvious problem with inlining everything is the loss of caching. If the HTML holds all the resources, and the HTML is not cacheable by itself, the resources are re-downloaded every time. This means the first page load on a new site may be faster, but subsequent pages or return visitors would experience a slower page load.

例如，我们看一下《纽约时报》首页的重复访问情况（表3-1、图3-1）。得益于缓存，原始站点加载时间为 2.7 秒。如果我们内联该页面上的 JavaScript 文件，重复访问加载时间将攀升至 3.2 秒，并且大小会加倍。从视觉上看，由于 JavaScript 对渲染的影响，负面影响要大得多。

For example, let’s look at the repeat visit of the New York Times’ home page (Table 3-1, Figure 3-1). Thanks to caching, the original site loads in 2.7 seconds. If we inline the JavaScript files on that page, the repeat visit load time climbs to 3.2 seconds, and the size doubles. Visually, the negative impact is much greater, due to JavaScript’s impact on rendering.

图 3-1。纽约时报网

Figure 3-1. www.nyt.com

即使 HTML 是可缓存的，缓存持续时间也必须是页面上所有资源的最短持续时间。如果您的 HTML 可缓存 10 分钟，并且页面中的资源可缓存一天，那么您实际上也将资源的可缓存性降低到 10 分钟。

Even if the HTML is cacheable, the cache duration has to be the shortest duration of all the resources on the page. If your HTML is cacheable for 10 minutes, and a resource in the page is cacheable for a day, you’re effectively reducing the cacheability of the resource to be 10 minutes as well.

CDN 的传统价值称为边缘缓存：在 CDN 边缘缓存静态资源。缓存资源直接从边缘提供，因此比一路路由到源服务器获取资源要快得多。

The traditional value of CDNs is called Edge Caching: caching static resources on the CDN edge. Cached resources are served directly from the edge, and thus delivered much faster than routing all the way to the origin server to get them.

内联数据时，资源被捆绑到 HTML 中，从 CDN 的角度来看，整个事情只是一个 HTTP 响应。如果 HTML 不可缓存，则整个 HTTP 响应也不可缓存。因此，每次用户请求页面时，都需要从源获取 HTML 及其所有资源，而在标准情况下，许多资源可以从边缘缓存提供。

When inlining data, the resources are bundled into the HTML, and from the CDN’s perspective, the whole thing is just one HTTP response. If the HTML is not cacheable, this entire HTTP response isn’t cacheable either. Therefore, the HTML and all of its resources would need to be fetched from the origin every time a user requests the page, while in the standard case many of the resources could have been served from the Edge Cache.

因此，即使是首次访问您网站的访问者，从具有内联资源的页面获得的体验也可能比从具有链接资源的页面获得的体验慢。当客户端从远离服务器的位置进行浏览时尤其如此。

As a result, even first-time visitors to your site are likely to get a slower experience from a page with inlined resources than from a page with linked resources. This is especially true when the client is browsing from a location far from your server.

例如，让我们看一下从巴西使用 IE8 和电缆连接浏览 Apple 主页。（表 3-2、 图 3-2）将站点修改为内联图像将加载时间从约 2.4 秒增加到约 3.1 秒，这可能是因为内联图像数据必须从原始服务器而不是 CDN 获取。虽然请求数量减少了 30%，但页面速度实际上变慢了。

For example, let’s take a look at browsing the Apple home page from Brazil, using IE8 and a cable connection. (Table 3-2, Figure 3-2) Modifying the site to inline images increased the load time from about 2.4s to about 3.1s, likely since the inlined image data had to be fetched from the original servers and not the CDN. While the number of requests decreased by 30%, the page was in fact slower.

图 3-2。苹果网站

Figure 3-2. www.apple.com

按需加载资源是性能优化的一个重要类别，它尝试仅在实际需要时加载资源。资源可以被引用，但在条件需要之前不会被实际下载和评估。

Loading resources on-demand is an important category of performance optimizations, which attempt to only load a resource when it’s actually required. Resources may be referenced, but not actually downloaded and evaluated until the conditions require it.

浏览器为 CSS 图像提供内置的按需加载机制。如果 CSS 规则引用了背景图像，则仅当页面上至少有一个元素与该规则匹配时，浏览器才会下载该图像。另一个例子是按需加载图像（http://www.blaze.io/technical/the-impact-of-image-optimization/），它仅在页面图像滚动到视图中时下载它们。移动网页设计的渐进增强方法使用类似的概念，仅根据需要加载 JavaScript 和 CSS。

Browsers offer a built-in loading-on-demand mechanism for CSS images. If a CSS rule references a background image, the browser would only download it if at least one element on the page matched the rule. Another example is loading images on-demand (http://www.blaze.io/technical/the-impact-of-image-optimization/), which only downloads page images as they scroll into view. The Progressive Enhancement approach to Mobile Web Design uses similar concepts for loading JavaScript and CSS only as needed.

由于内联资源是服务器上做出的决定，因此它不会从按需加载中受益。这意味着所有图像（CSS 或页面图像）都会被嵌入，无论特定客户端上下文是否需要它们。通常，通过内联获得的价值低于因不进行这些其他优化而损失的价值。

Since inlining resources is a decision made on the server, it doesn’t benefit from loading on-demand. This means all the images (CSS or page images) are embedded, whether they’re needed by the specific client context or not. More often than not, the value gained by inlining is lower than the value lost by not having these other optimizations.

作为一个例子，我以《太阳报》的主页为例，对其应用了两种相互冲突的优化（表3-3， 图3-3）。第一个按需加载图像，第二个内联所有图像。按需加载图像时，页面大小加起来约为 1MB，加载时间约为 9 秒。内联图像时，页面大小增加到近 2MB，加载时间增加到 16 秒。无论哪种方式，页面都会发出许多请求，但内联图像和按需图像之间的负载和大小差异非常明显。

As an example, I took The Sun’s home page and applied two conflicting optimizations to it (Table 3-3, Figure 3-3). The first loads images on demand, and the second inlines all images. When loading images on demand, the page size added up to about 1MB, and load time was around 9 seconds. When inlining images, the page size grew to almost 2MB, and the load time increased to 16 seconds. Either way the page makes many requests, but the load and size differences between inlining images and images on-demand are very noticeable.

图 3-3。www.thesun.co.uk

Figure 3-3. www.thesun.co.uk

现代浏览器使用智能启发式方法来尝试提前预取页面底部的资源。例如，如果您的网站在 HTML 末尾 引用了http://www.3rdparty.com/code.js ，则浏览器可能会解析www.3rdparty.com的 DNS ，甚至可能开始下载该文件，早在它能够实际执行之前。

Modern browsers use smart heuristics to try and prefetch resources at the bottom of the page ahead of time. For instance, if your site references http://www.3rdparty.com/code.js towards the end of the HTML, the browser is likely to resolve the DNS for www.3rdparty.com, and probably even start downloading the file, long before it can actually execute it.

在标准网站中，HTML 本身很小，因此浏览器只需下载几十 KB 即可看到整个 HTML。一旦它看到（并解析）整个 HTML，它就可以开始预取它认为合适的内容。如果大量使用内联，HTML 本身会变得更大，大小可能超过 0.5MB。下载时，浏览器无法查看和加速页面下方的资源，其中许多是您无法内联的第三方工具。

In a standard website, the HTML itself is small, and so the browser only needs to download a few dozen KB before it sees the entire HTML. Once it sees (and parses) the entire HTML, it can start prefetching as it sees fit. If you’re making heavy use of inlining, the HTML itself becomes much bigger, possibly over 0.5MB in size. While downloading it, the browser can’t see and accelerate the resources further down the page—many of which are third-party tools you couldn’t inline.

缓存问题的部分解决方案的工作原理如下：

A partial solution to the caching problem works as follows:

虽然总比没有好，但该解决方案的缺陷是它假设页面要么完全缓存，要么完全不缓存。事实上，网站和缓存状态非常不稳定。用户的缓存只能容纳不到一天的浏览数据：平均用户每天浏览 88 个页面 ( http://blog.newrelic.com/wp-content/uploads/infog_061611.png )，平均页面大小为 930KB ( http://httparchive.org/interesting.php#bytesperpage )，大多数桌面浏览器缓存的数据不超过 75MB ( http://www.blaze.io/mobile/understanding-mobile-cache-sizes/ )。对于移动设备来说，这个比例甚至更糟。

While better than nothing, the flaw in this solution is that it assumes a page is either entirely cached or entirely not cached. In reality, websites and cache states are extremely volatile. A user’s cache can only hold less than a day’s worth of browsing data: An average user browses 88 pages/day (http://blog.newrelic.com/wp-content/uploads/infog_061611.png), an average page weighs 930KB (http://httparchive.org/interesting.php#bytesperpage), and most desktop browsers cache no more than 75MB of data (http://www.blaze.io/mobile/understanding-mobile-cache-sizes/). For mobile, the ratio is even worse.

另一方面，Cookie 通常会在规定的到期日之前有效。因此，使用 cookie 来预测缓存状态很快就会变得毫无意义，然后您就会回到根本不内联的状态。

Cookies, on the other hand, usually live until their defined expiry date. Therefore, using a cookie to predict the cache state becomes pointless very quickly, and then you’re just back to not inlining at all.

该解决方案的最大问题之一是它的演示效果比实际效果更好。在综合测试中，如 WebPageTest 测试，页面确实要么完全缓存（即，其所有资源都被缓存），要么根本不缓存。因此，这些测试使首次访问内联方法看起来像是万能的，这是完全错误的。

One of the biggest problems with this solution is that it demos better than it really is. In synthetic testing, like WebPageTest tests, a page is indeed either fully cached (i.e., all its resources are cached), or it’s not cached at all. These tests therefore make the inline-on-first-visit approach look like the be all and end all, which is just plain wrong.

另一个重要问题是并非所有 CDN 都支持通过 cookie 改变缓存。因此，如果您的某些页面是可缓存的，或者您认为稍后可以将它们设置为可缓存的，则可能很难甚至不可能让 CDN 缓存页面的两个不同版本，并根据 cookie 选择要提供服务的版本。

Another significant problem is that not all CDNs support varying cache by a cookie. Therefore, if some of your pages are cacheable, or if you think you might make them cacheable later, it may be hard to impossible to get the CDN to cache two different versions of your page, and choose the one to serve based on a cookie.

我们的世界不是非黑即白的。减少请求数量是加速网站速度的好方法，但这并不意味着它是唯一的解决方案。如果你做得太过分，你最终会减慢你的网站速度，而不是加快速度。

Our world isn’t black and white. The fact that reducing the number of requests is a good way to accelerate your site doesn’t mean it’s the only solution. If you take it too far, you’ll end up slowing down your site, not speeding it up.

尽管有这些限制，内联仍然是前端优化领域中一个很好且重要的工具。因此，您应该使用它，但要小心不要滥用它。以下是有关何时使用内联的一些建议，但请记住，您应该验证它们是否在您自己的网站上获得了正确的效果：

Despite all these limitations, inlining is still a good and important tool in the world of frontend Optimization. As such, you should use it, but be careful not to abuse it. Here are some recommendations about when to use inlining, but keep in mind you should verify that they get the right effect on your own site:

Facebook JavaScript SDK是一段多用途代码，可让您集成 Facebook 服务、进行 API 调用以及加载社交插件，例如“赞”按钮 ( https://developers.facebook.com/docs/reference/plugins/like /）。

The Facebook JavaScript SDK is a multipurpose piece of code that lets you integrate Facebook services, make API calls, and load social plug-ins such as the Like button (https://developers.facebook.com/docs/reference/plugins/like/).

当涉及“赞”按钮和其他社交插件时，SDK 的任务是解析页面的 HTML 代码，查找要替换为 插件的元素（例如<fb:like>或）。<div class="fb-like">插件本身是一个 iframe，它指向 facebook.com/plugins/like.php具有适当 URL 参数和适当大小的内容。

The task of the SDK when it comes to Like button and other social plug-ins is to parse the page’s HTML code looking for elements (such as <fb:like> or <div class="fb-like">) to replace with a plug-in. The plug-in itself is an iframe that points to something like facebook.com/plugins/like.php with the appropriate URL parameters and appropriately sized.

这是此类插件 URL 的示例：

This is an example of one such plug-in URL:

https://www.facebook.com/plugins/like.php?href=bookofspeed.com&layout=box_count

https://www.facebook.com/plugins/like.php?href=bookofspeed.com&layout=box_count

JavaScript SDK 的 URL 如下所示：

The JavaScript SDK has a URL like so:

http://connect.facebook.net/en_US/all.js

http://connect.facebook.net/en_US/all.js

问题是如何将此代码包含在您的页面上。传统上，这是最简单的（但阻塞）方式：

The question is how do you include this code on your page. Traditionally it has been the simplest possible (but blocking) way:

<script src="http://connect.facebook.net/en_US/all.js"></script>

<script src="http://connect.facebook.net/en_US/all.js"></script>

不过，从社交插件诞生的第一天起，就一直可以异步加载该脚本，并且保证可以正常工作。此外，几个月前，当各种向导类型配置器生成 SDK 片段代码时，异步片段成为默认值。

Since day one of the social plug-ins though, it has always been possible to load this script asynchronously and it was guaranteed to work. Additionally, a few months ago the async snippet became the default when SDK snippet code is being generated by the various wizard-type configurators.

图 4-1显示了示例配置器的外观。

Figure 4-1 shows how an example configurator looks like.

图 4-1。喜欢按钮配置器

Figure 4-1. Like button configurator

异步代码看起来比传统代码更复杂（更长），但对于主机页面的整体加载速度来说，这是非常值得的。

The async code looks more complicated (it’s longer) than the traditional one, but it’s well worth it for the overall loading speed of the host page.

在检查此代码片段之前，让我们看看设计第三方提供商代码片段时的一些目标是什么。

Before we inspect this snippet, let’s see what some of the goals were when designing a third-party provider snippet.

Facebook 插件配置器中的代码片段如下所示：

The snippet in the Facebook plug-in configurators looks like so:

<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

看看这里发生了什么。

Take a look at what’s going on here.

在第一行和最后一行，您会看到整个代码段被包装在一个立即（又名，自调用，又名自执行）函数中。这是为了确保任何临时变量保留在本地范围内，并且不会渗透到主机页面的全局命名空间中。

On the first and last line you see that the whole snippet is wrapped in an immediate (a.k.a., self-invoking, aka self-executing) function. This is to assure that any temporary variables remain in the local scope and don’t bleed into the host page’s global namespace.

在第 1 行，您还可以看到立即函数接受三个参数，这些参数在调用函数时在最后一行提供。这些参数是document对象和两个字符串的简写，所有这些参数稍后都会在函数中多次使用。将它们作为参数传递比在函数体中定义它们要短一些。它还节省了一行（垂直空间），因为另一个选项类似于：

On line 1, you can also see that the immediate function accepts three arguments, and these are supplied on the last line when the function is invoked. These arguments are shorthands to the document object and two strings, all of which are used more than once later in the function. Passing them as arguments is somewhat shorter than defining them in the body of the function. It also saves a line (vertical space), because the other option is something like:

<script>(function() {
  var js, fjs = d.getElementsByTagName(s)[0],
      d = document, s = 'script', id = 'facebook-jssdk';
  // the rest...
}());</script>

<script>(function() {
  var js, fjs = d.getElementsByTagName(s)[0],
      d = document, s = 'script', id = 'facebook-jssdk';
  // the rest...
}());</script>

这将多一行（记住我们需要可读的片段，而不是过长的行）。此外，第一行和最后一行将有“未使用”的空间，因为它们有点短。

This would be one line longer (remember we want readable snippet, not overly long lines). Also the first and the last line will have “unused” space as they are somewhat short.

将重复document分配给较短的 d 之类的东西会使整个片段更短，并且可能会稍微快一些，因为 d 是本地的，查找速度比全局更快document。

Having things like the repeating document assigned to a shorter d makes the whole snippet shorter and also probably marginally faster as d is local which is looked up faster than the global document.

接下来我们有：

Next we have:

var js, fjs = d.getElementsByTagName(s)[0];

var js, fjs = d.getElementsByTagName(s)[0];

此行声明一个变量并查找<script>页面上的第一个可用元素。我稍后会讲到这一点。

This line declares a variable and finds the first available <script> element on the page. I’ll get to that in a second.

第 3 行检查脚本是否已经存在于页面上，如果是，则提前退出，因为没有其他事情可做：

Line 3 checks whether the script isn’t already on the page and if so, exits early as there’s nothing more to do:

if (d.getElementById(id)) return;

if (d.getElementById(id)) return;

我们只需要该文件一次。当人们在同一页面上多次复制并粘贴此代码时，此行可防止脚本文件被多次包含。对于常规的阻止脚本标记来说，这尤其糟糕，因为最终结果类似于（假设页面的博客文章类型）：

We only need the file once. This line prevents the script file from being included several times when people copy and paste this code multiple times on the same page. This is especially bad with a regular blocking script tag because the end result is something like (assuming a blog post type of page):

<script src="...all.js"></script>
<fb:like /> <!-- one like button at the top of the blog post -->

<script src="...all.js"></script>
<fb:like/> <!-- second like like button at the end of the post -->

<script src="...all.js"></script>
<fb:comments/> <!-- comments plugin after the article -->

<script src="...all.js"></script>
<fb:recommendations/> <!-- sidebar with recommendations plugin -->

<script src="...all.js"></script>
<fb:like /> <!-- one like button at the top of the blog post -->

<script src="...all.js"></script>
<fb:like/> <!-- second like like button at the end of the post -->

<script src="...all.js"></script>
<fb:comments/> <!-- comments plugin after the article -->

<script src="...all.js"></script>
<fb:recommendations/> <!-- sidebar with recommendations plugin -->

这会导致重复的 JavaScript，这很糟糕 ( http://developer.yahoo.com/performance/rules.html#js_dupes )，因为某些浏览器最终可能会多次下载该文件。

This results in a duplicate JavaScript, which is all kinds of bad (http://developer.yahoo.com/performance/rules.html#js_dupes), because some browsers may end up downloading the file several times.

即使 JavaScript 是异步的，即使浏览器足够聪明，不会重新解析它，它仍然需要重新执行它，在这种情况下，脚本会覆盖自身，一次又一次地重新定义其函数和对象。非常不受欢迎。

Even if the JavaScript is asynchronous and even if the browser is smart enough not to reparse it, it will still need to re-execute it, in which case the script overwrites itself, redefining its functions and objects again and again. Highly undesirable.

因此，具有类似 id 的脚本'facebook-jssdk'不太可能与主机页面上的某些内容发生冲突，让我们检查该文件是否已包含在内。如果情况并非如此，我们继续前进。

So having the script with an id like 'facebook-jssdk' which is unlikely to clash with something on the host page, lets us check if the file has already been included. If that’s not the case, we move on.

下一行创建一个script 元素并分配 ID，以便我们稍后检查：

The next line creates a script element and assigns the ID so we can check for it later:

js = d.createElement(s); js.id = id;

js = d.createElement(s); js.id = id;

以下行设置脚本的源：

The following line sets the source of the script:

js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";

js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";

请注意，URL 的协议丢失。这意味着将使用主机页面的协议加载脚本。如果主机页面使用http://，脚本加载速度会更快，如果页面使用，https:// 将不会出现混合内容安全提示。

Note that the protocol of the URL is missing. This means that the script will be loaded using the host page’s protocol. If the host page uses http://, the script will load faster, and if the page uses https:// there will be no mixed content security prompts.

最后，我们将新创建的js元素附加到主页的 DOM 中，就完成了：

Finally, we append the newly created js element to the DOM of the host page and we’re done:

fjs.parentNode.insertBefore(js, fjs);

fjs.parentNode.insertBefore(js, fjs);

这是如何运作的？嗯，fjs是页面上可用的第一个 (f) JavaScript (js) 元素。我们早些时候在第 2 行抓住了它。js我们在 之前插入新元素fjs。假设，如果主页在 后面有一个 script 元素body，那么：

How does that work? Well, fjs is the first (f) JavaScript (js) element available on the page. We grabbed it earlier on line #2. We insert our new js element right before the fjs. If, let’s say, the host page has a script element right after the body, then:

为什么整个都出问题了parentNode.insertBefore？有更简单的方法可以将节点添加到 DOM 树，例如使用附加到<head>或，但是这是保证在几乎所有情况下都有效的方法。让我们看看其他人失败的原因。<body>appendChild()

Why the trouble with the whole parentNode.insertBefore? There are simpler ways to add a node to the DOM tree, like appending to the <head> or to the <body> by using appendChild(), however this is the way that is guaranteed to work in nearly all cases. Let’s see why the others fail.

这是一个常见的模式：

Here is a common pattern:

document.getElementsByTagName('head')[0].appendChild(js);

document.getElementsByTagName('head')[0].appendChild(js);

或者在较新的浏览器中可用的变体document.head ：

Or a variation if document.head is available in newer browsers:

(document.head || document.getElementsByTagName('head')[0]).appendChild(js);

(document.head || document.getElementsByTagName('head')[0]).appendChild(js);

问题是您无法控制主页的标记。如果页面没有元素怎么办head？浏览器无论如何都会创建该节点吗？事实证明，大多数情况下，是的，但有些浏览器（Opera 8、Android 1）不会创建头部。Steve Souders 的 BrowserScope 测试证明了这一点 ( http://stevesouders.com/tests/autohead.html )。

The problem is that you don’t control the markup of the host page. What if the page doesn’t have a head element? Will the browser create that node anyways? Turns out that most of the times, yes, but there are browsers (Opera 8, Android 1) that won’t create the head. A BrowserScope test by Steve Souders demonstrates this (http://stevesouders.com/tests/autohead.html).

那么呢body？你得有身体。所以你应该能够做到：

What about the body? You gotta have the body. So you should be able to do:

document.body.appendChild(js);

document.body.appendChild(js);

我创建了一个 browserscope 测试（http://www.phpied.com/files/bscope/autobody.html），但找不到不会创建的浏览器 document.body。但是当异步代码片段脚本元素是嵌套的而不是主体的直接子元素时，IE7 中仍然会出现可爱的“操作中止”错误。

I created a browserscope test (http://www.phpied.com/files/bscope/autobody.html) and couldn’t find a browser that will not create document.body. But there’s still the lovely “Operation Aborted” error which occurs in IE7 when the async snippet script element is nested and not a direct child of the body.

最后的机会：

Last chance:

document.documentElement.firstChild.appendChild(js);

document.documentElement.firstChild.appendChild(js);

document.documentElement是 HTML 元素，它的第一个子元素必须是 head。事实证明不一定。如果 HTML 元素后面有注释，WebKit 会将注释作为第一个子元素提供给您。有一个测试用例的调查显示了这一点（http://robert.accettura.com/blog/2009/12/12/adventures-with-document-documentelement-firstchild/）。

document.documentElement is the HTML element and its first child must be the head. Not necessarily, as it turns out. If there’s a comment following the HTML element, WebKits will give you the comment as the first child. There’s an investigation with a test case that show this (http://robert.accettura.com/blog/2009/12/12/adventures-with-document-documentelement-firstchild/).

尽管有可能的替代方案，但使用第一个可用script节点似乎insertBefore是最具弹性的选项。总是至少有一个script节点，即使那是script片段本身的节点。

Despite the possible alternatives, it appears that using the first available script node and insertBefore is the most resilient option. There’s always going to be at least one script node, even if that’s the script node of the snippet itself.

（嗯，“总是”在 Web 开发中是一个很重的词。正如 @kangax ( http://twitter.com/kangax ) 曾经指出的那样，您可以将代码片段放在 a 中，<body onload="...">瞧——神奇！——一个没有script节点的脚本.)

(Well, “always” is a strong word in web development. As @kangax (http://twitter.com/kangax) pointed out once, you can have the snippet inside a <body onload="..."> and voila—magic!—a script without a script node.)

您可能会注意到此代码片段中缺少一些您可能在其他代码示例中看到的内容。

You may notice some things missing in this snippet that you may have seen in other code examples.

例如，没有：

For instance there are none of:

js.async = true;
js.type = "text/javascript";
js.language = "JavaScript";

js.async = true;
js.type = "text/javascript";
js.language = "JavaScript";

这些都是默认的，不需要占用空间，所以就省略了。一些早期的 Firefox 版本是例外async，但脚本已经足够非阻塞和异步了。

These are all defaults which don’t need to take up space, so they were omitted. Exception is the async in some earlier Firefox versions, but the script is already nonblocking and asynchronous enough anyway.

标签本身也是如此<script> 。它是一个 HTML5 有效的基本标签，没有type或language属性。

Same goes for the <script> tag itself. It’s an HTML5-valid bare-bones tag with no type or language attributes.

整个讨论是从第三方脚本提供商的角度出发的。如果您控制标记，有些事情可能会有所不同并且更容易。您可以安全地引用头部，因为您知道它就在那里。您不必检查重复插入，因为您只需插入一次。所以你最终可能会得到更简单的东西，例如：

This whole discussion was from the perspective of a third-party script provider. If you control the markup, some things might be different and easier. You can safely refer to the head because you know it’s there. You don’t have to check for duplicate insertions, because you’re only going to insert it once. So you may end up with something much simpler, such as:

<script>(function(d) {
  var js = d.createElement('script');
  js.src = "http://example.org/my.js";
  (d.head || d.getElementsByTagName('head')[0]).appendChild(js);
}(document));</script>

<script>(function(d) {
  var js = d.createElement('script');
  js.src = "http://example.org/my.js";
  (d.head || d.getElementsByTagName('head')[0]).appendChild(js);
}(document));</script>

这就是您控制主页时所需要的一切。

This is all it takes when you control the host page.

此外，我们一直假设只要脚本到达，它就会运行。但您可能有不同的需求，例如在脚本准备好后调用特定函数。在这种情况下，您需要收听 js.onload和js.onreadystatechange（例如： http: //www.phpied.com/javascript-include-ready-onload/）。在更复杂的示例中，您可能需要加载多个脚本并保证它们的执行顺序。此时，您可能需要查看任何可用的脚本加载器项目，例如 LAB.js ( http://labjs.com/ ) 或 head.js ( http://headjs.com/ )，它们专门设计用于解决这些案例。

Also we assumed all the time that whenever the script arrives, it just runs. But you may have different needs, for example call a specific function once the script is ready. In which case you need to listen to js.onload and js.onreadystatechange (example: http://www.phpied.com/javascript-include-ready-onload/). In even more complex examples, you may want to load several scripts and guarantee their order of execution. At this point you may want to look into any of the available script loader projects such as LAB.js (http://labjs.com/) or head.js (http://headjs.com/) which are specially designed to solve these cases.

有点令人不安的是，我们 Web 开发人员需要竭尽全力来确保异步脚本执行（无论是否在第三方环境中）。有一天，当我们身后有一些死浏览器时，我们将能够简单地说script async=true，它会正常工作。同时，我希望这篇文章能够作为尚未解决此问题的人们的资源减轻一些痛苦，并有望为他们节省一些时间。

It’s a little disturbing that we, the web developers, need to go to all these lengths to assure an asynchronous script execution (in a third-party environment or not). One day, with a few dead browsers behind us, we’ll be able to simply say script async=true and it will just work. Meanwhile, I hope that this post will alleviate some of the pain as a resource to people who are yet to come to this problem and will hopefully save them some time.

Google AdSense 人员在与社区分享他们的进展时经历了很多尝试和错误，Mathias Bynens 还为他们的代码片段写了一篇鼓舞人心的评论 ( http://mathiasbynens.be/notes/async-analytics-snippet )。Steve Souders ( http://stevesouders.com/ ) 对此主题进行了研究并撰写了文章，MSN.com 可能是最早使用这种加载 JavaScript 技术的网站之一。雅虎和许多其他公司都有关于该主题的文章。这些是帮助寻找“完美”片段的一些巨头。谢谢你！

Google AdSense folks have gone through a lot of trial and error while sharing their progress with the community, and Mathias Bynens also wrote an inspirational critique (http://mathiasbynens.be/notes/async-analytics-snippet) of their snippet. Steve Souders (http://stevesouders.com/) has done research and written about this topic, and MSN.com was probably among the first to use such a technique for loading JavaScript. There are writeups from Yahoo and many others on the topic. These are some of the giants that have helped in the search of the “perfect” snippet. Thank you!

（嘘，如果您在代码片段中看到一些不完美的地方，请大声说出来！）

(Psst, and if you see something that is less than perfect in the snippet, please speak up!)

系统的复杂度可能由其变量的数量决定，而运营商网络的变量也非常多。它们的性能会根据位置、使用网络的人数、天气、运营商等因素而发生巨大变化，没有什么可以保证您能够保持静态。

The complexity of a system may be determined by the number of its variables, and carrier networks have a lot of variables. Their performance varies dramatically depending on factors such as location, the number of people using a network, the weather, the carrier—there isn’t much that you can rely on to remain static.

一项研究 ( http://www.pcworld.com/article/167391/a_day_in_the_life_of_3g.html ) 证明了不同地点之间存在多大差异。该测试涉及检查美国各个城市的三个不同移动运营商（Sprint、Verizon 和 AT&T）的 3G 网络带宽。结果的多样性令人震惊。

One study (http://www.pcworld.com/article/167391/a_day_in_the_life_of_3g.html) demonstrated just how much variance there can be from location to location. The test involved checking bandwidth on 3G networks for three different mobile carriers—Sprint, Verizon, and AT&T—in various cities across the United States. The diversity of the results were stunning.

新奥尔良 Verizon 网络的最高记录带宽为 1425 kbps。纽约市 AT&T 的速度最低为 477 kbps，相差 948 kbps。即使在单个运营商内，这种差异也是显着的。虽然 Verizon 的最高带宽为 1425 kbps，但在俄勒冈州波特兰，其记录的最低带宽为 622 kbps。

The highest recorded bandwidth was 1425 kbps in New Orleans on a Verizon network. The lowest was 477 kbps in New York City in AT&T—a difference of 948 kbps. Even within a single carrier, the variation was remarkable. While Verizon topped out at 1425 kbps, their lowest recorded bandwidth was 622 kbps in Portland, Oregon.

另一个非正式实验（http://www.webperformancetoday.com/2011/10/26/interesting-findings-3g-mobile-performance-is-up-to-10x-slower-than-throttled-broadband-service/）是最近由约书亚·比克斯比 (Joshua Bixby) 指挥。Joshua 随机记录了他的 3G 网络的带宽和延迟量。即使在他家这个单一位置，延迟也从 100 多毫秒一直到 350 毫秒不等。

Another informal experiment (http://www.webperformancetoday.com/2011/10/26/interesting-findings-3g-mobile-performance-is-up-to-10x-slower-than-throttled-broadband-service/) was recently conducted by Joshua Bixby. Joshua randomly recorded the amounts of bandwidth and latency on his 3G network. Even within a single location, his house, the latency varied from just over 100 ms all the way up to 350 ms.

已发布的有关移动网络延迟的信息非常少。2010 年，雅虎！根据他们所做的一项小型研究（ http://www.yuiblog.com/blog/2010/04/08/analyzing-bandwidth-and-latency/ ）发布了一些信息。进入 YUI 博客的流量受到带宽和延迟的监控。这些数字按连接类型进行平均，并将结果以图表形式发布。他们的研究表明，移动连接的平均延迟为 430 毫秒，而有线连接的平均延迟仅为 130 毫秒。

Remarkably little information about mobile network latency has been published. In 2010, Yahoo! released some information based on a small study (http://www.yuiblog.com/blog/2010/04/08/analyzing-bandwidth-and-latency/) they had done. Traffic coming into the YUI blog was monitored for both bandwidth and latency. These numbers were averaged by connection type and the results published as a graph. Their study showed that the average latency for a mobile connection was 430 ms, compared to only 130 ms for an average cable connection.

这项研究并非万无一失。样本量很小，访问 YUI 博客的受众类型并不完全代表普通人。至少是公开发布的数据。迄今为止发布的其余大部分延迟数据都没有太多背景信息；通常没有提及它是如何测量的。

The study isn’t foolproof. The sample size was small and the type of audience that would be visiting the YUI blog is not exactly a representation of the average person. At least it was publicly released data. Most of the rest of the latency numbers released so far come without much context; there usually isn’t any mention of how it was measured.

移动网络的另一个问题是运营商转码引起的频繁问题。例如，许多网络尝试减小图像的文件大小。有时，这是在不被注意的情况下完成的。然而，结果通常是图像变得颗粒状或模糊，并且网站的外观受到负面影响。

Another concern with mobile networks are frequent issues caused by carrier transcoding. Many networks, for example, attempt to reduce the file size of images. Sometimes, this is done without being noticed. Often, however, the result is that images become grainy or blurry and the appearance of the site is affected in a negative way.

英国《金融时报》致力于通过使用 dataURI 来避免其移动 Web 应用程序出现此问题 ( http://www.tomhume.org/2011/10/appftcom-and-the-cost-of-cross-platform-web-apps. html），但即使这种技术也不是完全安全的。虽然该问题尚未得到充分记录或孤立，但英国的一些开发人员报告说，英国最大的移动提供商之一 O2 有时会删除 dataURI。

The Financial Times worked to avoid this issue with their mobile web app by using dataURIs instead (http://www.tomhume.org/2011/10/appftcom-and-the-cost-of-cross-platform-web-apps.html), but even this technique is not entirely safe. While the issue is not well documented or isolated yet, a few developers in the UK have reported that O2, one of the largest mobile providers in the UK, will sometimes strip out dataURIs.

转码并不止于图像。T-Mobile 最近被发现删除了任何看起来像 Javascript 评论的内容 ( http://www.mysociety.org/2011/08/11/mobile-operators-breaking-content/ )。这些意图大多是光荣的，但方法却会带来问题。例如，jQuery 库有一个包含*/*. 稍后在库中，您可以再次找到相同的字符串。看到这两个字符串后，T-Mobile 会删除中间的所有内容，从而在此过程中破坏许多网站。

Transcoding doesn’t stop at images. T-Mobile was recently found to be stripping out anything that looked like a Javascript comment (http://www.mysociety.org/2011/08/11/mobile-operators-breaking-content/). The intentions were mostly honorable, but the method leads to issues. The jQuery library, for example, has a string that contains */*. Later on in the library, you can again find the same string. Seeing these two strings, T-Mobile would then strip out everything that was in between—breaking many sites in the process.

这种转码方法也可能会给任何试图通过首先注释掉 JavaScript 来延迟加载的人带来问题（http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing .html ) — 一种流行且有效的技术，用于改进解析和页面加载时间。

This method of transcoding could also create issues for anyone who is trying to lazy-load their Javascript by first commenting it out (http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html) — a popular and effective technique for improving parse and page load time.

运营商Optus不仅通过降低图像分辨率导致图像模糊，而且还会以阻塞的方式向页面注入外部脚本（http://www.zdnet.com.au/optus-3g-accelerator-spawns-模糊图片-339303393.htm）。不幸的是，大多数这些转码问题和技术都没有被充分公开或记录良好。我怀疑还有无数其他人正在等待被发现。

One carrier, Optus, not only causes blurry images by lowering the image resolution, but also injects an external script into the page in a blocking manner (http://www.zdnet.com.au/optus-3g-accelerator-spawns-blurry-pics-339303393.htm). Unfortunately, most of these transcoding issues and techniques are not very exposed or well documented. I suspect countless others are just waiting to be discovered.

这听起来有点令人沮丧，但这不是这里的目标。我们需要进一步探索运营商网络，因为如果我们愿意深入挖掘，我们可以挖掘出令人难以置信的丰富信息。

This can all sound a bit discouraging, but that’s not the goal here. We need to explore carrier networks further because there is an incredible wealth of information we can unearth if we’re willing to dig far enough.

其中一个例子是 Steve Souders 最近测试的不活动计时器和状态机的想法 ( http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/ )。移动网络依靠不同的状态来确定分配的吞吐量，这反过来又会影响电池消耗。为了在状态之间进行向下切换（从而减少电池消耗，同时也减少吞吐量），运营商会发送一个不活动计时器。不活动计时器向设备发出信号，指示其应切换到更节能的状态。这可能会对性能产生很大影响，因为可能需要一两秒钟才能恢复到最高状态。正如您可能怀疑的那样，这个不活动计时器因运营商而异。史蒂夫已经设置了一个测试（http://stevesouders.com/ms/）您可以运行它来尝试确定不活动计时器可能在当前连接上触发的位置。结果虽然并非万无一失，但确实强烈表明这些计时器可能存在显着差异。

One example of this is the idea of inactivity timers and state machines that Steve Souders was recently testing (http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/). Mobile networks rely on different states to determine allotted throughput, which in turn affects battery drain. To down-switch between states (thereby reducing battery drain, but also throughput) the carrier sends an inactivity timer. The inactivity timer signals to the device that it should shift to a more energy-efficient state. This can have a large impact on performance because it can take a second or two to ramp back up to the highest state. This inactivity timer, as you might suspect, varies from carrier to carrier. Steve has set up a test (http://stevesouders.com/ms/) that you can run in an attempt to identify where the inactivity timer might fire on your current connection. The results, while not foolproof, do strongly suggest that these timers can be dramatically different.

我们需要更多此类信息和测试。网络最初并不是针对数据进行优化的；它们针对语音进行了优化。当 3G 网络推出时，人们期望数据流量的主要来源将来自图片消息等。唯一可访问的移动互联网是 WAP——一种非常简化的网络版本。

We need more of this kind of information and testing. Networks weren’t originally optimized for data; they were optimized for voice. When 3G networks were rolled out, the expectation was that the major source of data traffic would come from things like picture messaging. The only accessible mobile Internet was WAP—a very simplified version of the Web.

然而，随着设备的功能变得越来越强大，在这些设备上体验完整的互联网变得可能。人们开始期待看到的不仅仅是有限版本的互联网，而是整个互联网（视频、猫图片等等），导致网络不堪重负。

As devices became more and more capable, however, it became possible to experience the full Internet on these devices. People started expecting to see not just a limited version of the Internet, but the whole thing (videos, cat pictures, and all) leaving the networks overwhelmed.

毫无疑问，运营商正在采用与这些转码方法和状态机类似的其他技术来绕过其网络的限制，以便为更多客户提供更快的数据服务。

There are undoubtedly other techniques, similar to these transcoding methods and state machines, that carriers are doing to get around the limitations of their network in order to provide faster data services to more customers.

许多人喜欢指出即将推出的 4G 网络可以缓解这些担忧。在某种程度上，他们是对的——它确实有助于解决一些延迟和带宽问题。然而，对于运营商来说，进行这种转变是一项相当昂贵的努力，这意味着我们不应该指望在一夜之间广泛推出。

Many people like to point to the upcoming roll-out of 4G networks as a way of alleviating many of these concerns. To some extent, they’re right—it will indeed help with some of the latency and bandwidth issues. However, it’s a pretty costly endeavor for carriers to make that switch meaning that we shouldn’t expect widespread roll-out overnight.

即使进行了切换，我们也可以预期运营商使用的质量、覆盖范围和优化方法也不会统一。威廉·吉布森说：“未来已经到来，只是分布不均。” 移动连接也有非常相似的情况。

Even when the switch has been made we can expect that the quality, coverage and methods of optimization used by the carriers will not be uniform. William Gibson said, “The future is already here—it’s just not evenly distributed.” Something very similar could be said of mobile connectivity.

为了推动这一讨论，我们需要做一些事情。首先，改善开发商、制造商和运营商之间的沟通将大有帮助。如果不是 AT&T 的研究论文 ( http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient )，我们可能仍然不知道运营商状态机和不活动计时器对性能的影响。此类更多信息不仅提示我们优化移动性能的独特考虑因素，而且还为我们提供了一些视角。我们被提醒，这不仅仅与加载时间有关；还与加载时间有关。还有其他因素在起作用，我们需要考虑权衡。

To move this discussion forward, we need a few things. For starters, some improved communication between developers, manufacturers, and carriers would go a long, long way. If not for AT&T’s research paper (http://www.research.att.com/articles/featured_stories/2011_03/201102_Energy_efficient), we may still not be aware of the performance impact of carrier state machines and inactivity timers. More information like this not only cues us into the unique considerations of optimizing for mobile performance, but also gives us a bit of perspective. We are reminded that it’s not just about load time; there are other factors at play and we need to consider the trade-offs.

改进的通信也可以大大减少由转码方法引起的问题。以 T-Mobile 错误删除评论为例。如果在实施此方法之前与开发人员进行某种公开对话，那么问题可能会在该功能上线之前就被发现。

Improved communication could also go a long way toward reducing the issues caused by transcoding methods. Take the case of T-Mobile’s erroneous comment stripping. Had there been some sort of open dialogue with developers before implementing this method, the issues would probably have been caught well before the feature made it live.

我们还可以使用更多工具。移动性能测试工具的数量和质量正在不断提高。然而，我们仍然可以使用很少的工具来测试真实设备和真实网络上的性能。随着导航计时 API的采用，这将有助于改善这种情况。然而，仍然有足够的空间来创建更强大的测试工具。

We could also use a few more tools. The number—and quality—of mobile performance testing tools is improving. Yet we still have precious few tools at our disposal for testing performance on real devices, over real networks. As the Navigation Timing API gains adoption, that will help to improve the situation. However, there will still be ample room for the creation of more robust testing tools as well.

你知道，最终爱丽丝走出了那个小房间。她继续经历了许多冒险并遇到了许多有趣的生物。醒来后，她想，这是一个多么美妙的梦啊。随着我们的工具不断改进，我们进一步探索这个兔子洞，有一天我们也将能够理解这一切。当我们做我们的应用程序时，我们的网站将会变得更好。

You know, eventually Alice gets out of that little room. She goes on to have many adventures and meet many interesting creatures. After she wakes up, she thinks what a wonderful dream it had been. As our tools continue to improve and we explore this rabbit hole further, one day we, too, will be able to make some sense of all of this. When we do our applications and our sites will be better for it.

图 6-1中的图像是瀑布图的一部分，显示了 IE8 浏览器为下载电子商务网站主页上的图形而执行的 HTTP 请求。

The image on Figure 6-1 is part of a waterfall diagram showing the HTTP requests that an IE8 browser performed to download the graphics on the home page of an e-commerce website.

图 6-1。阶梯瀑布图案

Figure 6-1. Stair-step waterfall pattern

此瀑布示例中看到的阶梯图案显示了几个值得注意的事情：

The stair-step pattern seen in this waterfall sample shows several noteworthy things:

有几种成熟的技术可以避免这种阶梯模式及其 (N * RTT / 6) 运行时间。除了使用 CDN 来降低 RTT 和客户端缓存来降低 N 的有效值外，网站开发人员还可以应用多种内容优化：

There are several well-established techniques for avoiding this stair-step pattern and its (N * RTT / 6) elapsed time. Besides using CDNs to reduce the RTT and client-side caching to reduce the effective value of N, the website developer can apply several content optimizations:

尽管这些内容优化众所周知，但图 6-1中的瀑布示例表明它们并不总是得到应用。根据作者的经验，即使是注重性能的组织有时也会推出速度较慢的网站，因为速度只是争夺有限开发时间的众多优先事项之一。​

Although these content optimizations are well known, examples like the waterfall in Figure 6-1 show that they are not always applied. In the author’s experience, even performance-conscious organizations sometimes launch slow websites, because speed is just one of many priorities competing for limited development time.​

因此，一个有趣的问题是：一般网站在多大程度上避免了阶梯式 HTTP 请求序列化模式？

Thus an interesting question is: how well has the average website avoided the stair-step HTTP request serialization pattern?

HTTP Archive ( http://httparchive.org/ ) 是一个包含 HTTP 请求详细记录的数据库，其中包括真实浏览器从 Alexa 下载全球数万个网站主页时发出的分辨率为 1ms 的计时数据热门网站列表。

The HTTP Archive (http://httparchive.org/) is a database containing detailed records of the HTTP requests–including timing data with 1ms resolution that a real browser issued when downloading the home pages of tens of thousands of websites from the Alexa worldwide top sites list.

通过这个数据集，我们可以在每个网页中找到序列化的请求序列。第一步是从 HTTP Archive下载每个页面的 HAR ( http://www.softwareishard.com/blog/har-12-spec/ ) 文件。该文件包含页面的 HTTP 请求列表，我们可以根据简单的启发式定义找到请求的序列化序列：​

With this data set, we can find serialized sequences of requests in each web page. The first step is to download each page’s HAR (http://www.softwareishard.com/blog/har-12-spec/) file from the HTTP Archive. This file contains a list of the HTTP requests for the page, and we can find serialized sequences of requests based on a simple, heuristic definition:​

此定义捕获了一组按顺序运行的 HTTP 请求的概念，因为浏览器缺乏并行运行它们的方法，而不是因为所请求的资源之间的内容相互依赖性。该定义出于谨慎考虑而犯了错误，排除了非图像请求，因为 JavaScript、CSS 或 SWF 文件可能是后续任何请求的先决条件。在接下来的讨论中，我们假设浏览器在序列开始时就知道序列化序列中所有图像的 URL，这有点过于乐观。​

This definition captures the concept of a set of HTTP requests that are run sequentially because the browser lacks a way to run them in parallel, rather than because of content interdependencies among the requested resources. The definition errs on the side of caution by excluding non-image requests, on the grounds that a JavaScript, CSS, or SWF file might be a prerequisite for any request that follows. In the discussion that follows, we err slightly on the side of optimism by assuming that the browser knew the URLs of all the images in a serialized sequence at the beginning of the sequence.​

图 6-2中的直方图显示了 HTTP Archive 2011 年 12 月 1 日数据集中的 49,854 个网页中每页最长序列化请求序列的分布。

The histogram on Figure 6-2 shows the distribution of the longest serialized request sequences per page among 49,854 web pages from the HTTP Archive’s December 1, 2011 data set.

图 6-2。每页最长序列化请求序列的分布

Figure 6-2. Distribution of the longest serialized request sequences per page

在本次调查中大约3%的网页中，没有请求序列化（即最长序列化请求长度为1）。从请求并行化的角度来看，这些页面已经得到了很好的优化。

In approximately 3% of the web pages in this survey, there is no serialization of requests (i.e., the longest serialized request length is one). From a request parallelization perspective, these pages already are quite well optimized.

在接下来的 30% 的网页中，最长的序列化请求序列的长度为二或三。这些页面可能会从增加的请求并行化中适度受益，并且像域分片这样的简单方法就足够了。

In the next 30% of the web pages, the longest serialized request sequence has a length of two or ​three. These pages might benefit modestly from increased request parallelization, and a simple approach like domain sharding would suffice.

其余三分之二的网页具有长度为 4 或更大的序列化请求序列。虽然内容优化可以改善这些页面的请求并行化，但如此多的网站具有如此多的序列化这一事实表明，内容优化的障碍并不小。​

The remaining two thirds of the web pages have serialized request sequences of length 4 or greater. While content optimizations could improve the request parallelization of these pages, the fact that so many sites have so much serialization suggests that the barriers to content optimization are nontrivial. ​

在不优化内容的情况下加速网站的一种方法是更广泛地实施 HTTP 请求管道。HTTP/1.1 自 RFC 2068 起就支持管道传输，但由于担心损坏的代理会错误处理管道化请求，大多数桌面浏览器尚未实现该功能。此外，队列头阻塞也是一个不小的问题。最近的工作重点是服务器向客户端提供有关哪些资源可以安全通过管道传输的提示（ http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 ）。然而，移动浏览器开始更普遍地使用管道技术。

One way to speed up websites without content optimization would be through more widespread implementation of HTTP request pipelining. HTTP/1.1 has supported pipelining since RFC 2068, but most desktop browsers have not implemented the feature due to concerns about broken proxies that mishandle pipelined requests. In addition, head-of-queue blocking is a nontrivial problem; recent efforts have focused on ways for the server to give the clients hints (http://tools.ietf.org/html/draft-nottingham-http-pipeline-01) about what resources are safe to pipeline. Mobile browsers, however, are beginning to use pipelining more commonly.

另一种方法是在 HTTP 下引入多路复用会话层，以便客户端可以并行发出请求。此策略的一个示例是 SPDY ( http://www.chromium.org/spdy )，目前在 Chrome 中受支持，很快 ( http://bitsup.blogspot.com/2011/11/video-of-spdy-talk- at-codebitseu.html）在 Firefox 中。

Another approach is to introduce a multiplexing session layer beneath HTTP, so that the client can issue requests in parallel. An example of this strategy is SPDY (http://www.chromium.org/spdy), supported currently in Chrome and soon (http://bitsup.blogspot.com/2011/11/video-of-spdy-talk-at-codebitseu.html) in Firefox.

无论是通过管道还是多路复用，业界似乎都值得寻求协议级解决方案来提高 HTTP 请求并行度。

Whether through pipelining or multiplexing, it appears worthwhile for the industry to pursue protocol-level solutions to increase HTTP request parallelization.

没过多久我就意识到问题出在前端 SPOF（http://www.stevesouders.com/blog/2010/06/01/frontend-spof/）——当前端资源（脚本、样式表或字体）文件）导致页面不可用。有些页面完全空白，例如 Business Insider（http://www.businessinsider.com，图 8-1）。

It didn’t take me long to realize the problem was frontend SPOF (http://www.stevesouders.com/blog/2010/06/01/frontend-spof/)—when a frontend resource (script, stylesheet, or font file) causes a page to be unusable. Some pages were completely blank, such as Business Insider (http://www.businessinsider.com, Figure 8-1).

Firebug 的网络面板显示anywhere.js下载需要很长时间，因为它来自platform.twitter.com– 被防火墙阻止。知道脚本会阻止所有后续 DOM 元素的渲染，我们假设anywhere.js在 HEAD 中以阻塞模式加载。查看 HTML 源代码，我们发现这正是发生的情况：

Firebug’s Net Panel shows that anywhere.js is taking a long time to download because it’s coming from platform.twitter.com – which is blocked by the firewall. Knowing that scripts block rendering of all subsequent DOM elements, we form the hypothesis that anywhere.js is being loaded in blocking mode in the HEAD. Looking at the HTML source, we see that’s exactly what is happening:

<head>
...
<!-- Twitter Anywhere -->
<script src="https://platform.twitter.com/anywhere.js?id=ZV0...&v=1"
        type="text/javascript"></script>
<!-- / Twitter Anywhere -->
...

</head>

<body>

<head>
...
<!-- Twitter Anywhere -->
<script src="https://platform.twitter.com/anywhere.js?id=ZV0...&v=1"
        type="text/javascript"></script>
<!-- / Twitter Anywhere -->
...

</head>

<body>

图 8-1。由于 Twitter 脚本被阻止而导致可怕的“空白屏幕”

Figure 8-1. The dreaded “blank white screen” due to a blocking Twitter script

如果anywhere.js异步加载（http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/），则不会发生这种情况。相反，由于anywhere.js使用旧方式加载<SCRIPT SRC=...，因此它会阻止后面的所有 DOM 元素，在本例中是页面的整个 BODY。如果我们等待足够长的时间，请求就会anywhere.js超时，页面就会开始渲染。请求多久会超时？查看 Business Insider 的“之后”屏幕截图，我们发现请求超时需要1 分 15 秒。用户盯着空白屏幕等待 Twitter 脚本的时间为 1 分 15 秒！（见图8-2。）

If anywhere.js had been loaded asynchronously (http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/) this wouldn’t happen. Instead, since anywhere.js is loaded the old way with <SCRIPT SRC=..., it blocks all the DOM elements that follow which in this case is the entire BODY of the page. If we wait long enough the request for anywhere.js times out and the page begins to render. How long does it take for the request to timeout? Looking at the “after” screenshot of Business Insider we see it takes 1 minute and 15 seconds for the request to timeout. That’s 1 minute and 15 seconds that the user is left staring at a blank white screen waiting for the Twitter script! (See Figure 8-2.)

图 8-2。Business Insider 最终在 1 分 15 秒后呈现

Figure 8-2. Business Insider finally renders after 1 minute 15 seconds

CNET ( http://www.cnet.com/ ) 的体验略有不同；显示导航标题，但页面的其余部分被阻止呈现（图 8-3）。

CNET (http://www.cnet.com/) has a slightly different experience; the navigation header is displayed but the rest of the page is blocked from rendering (Figure 8-3).

查看 Firebug，我们发现wrapper.jsfromcdn.eyewonder.com处于“待处理”状态 — 这一定是被防火墙阻止的另一个域。根据渲染停止的位置，我们猜测wrapper.jsSCRIPT 标签紧接在导航标题之后，并以阻塞模式加载，从而阻止页面的其余部分渲染。HTML 证实这确实是正在发生的事情：

Looking in Firebug we see that wrapper.js from cdn.eyewonder.com is “pending”—this must be another domain that’s blocked by the firewall. Based on where the rendering stops, our guess is that the wrapper.js SCRIPT tag is immediately after the navigation header and is loaded in blocking mode thus preventing the rest of the page from rendering. The HTML confirms that this is indeed what’s happening:

<header>
...
</header>

<script src="http://cdn.eyewonder.com/100125/771933/1592365/wrapper.js"></script>

<div id="rb_wrap">

<div id="rb_content"> <div id="contentMain">

<header>
...
</header>

<script src="http://cdn.eyewonder.com/100125/771933/1592365/wrapper.js"></script>

<div id="rb_wrap">

<div id="rb_content"> <div id="contentMain">

图 8-3。CNET 渲染被 eyewonder.com 的广告屏蔽

Figure 8-3. CNET rendering is blocked by ads from eyewonder.com

每天，我都会访问 O'Reilly Radar 阅读 Nat Torkington 的 ( http://radar.oreilly.com/nat/index.html ) 四个短链接。通常，Nat 是 Radar 头版上众多故事之一，但从北京前往那里，显示的页面只有一个故事（图 8-4）。

Everyday, I visit O’Reilly Radar to read Nat Torkington’s (http://radar.oreilly.com/nat/index.html) Four Short Links. Normally Nat’s is one of many stories on the Radar front page, but going there from Beijing shows a page with only one story (Figure 8-4).

在第一个故事的底部应该有一个推文按钮。此按钮是通过widgets.js从中获取的脚本添加的platform.twitter.com，该脚本被防火墙阻止。如果是异步获取的话，这不会成为问题widgets.js，但遗憾的是，查看 HTML 会发现情况并非如此：

At the bottom of this first story there’s supposed to be a Tweet button. This button is added by the widgets.js script fetched from platform.twitter.com which is blocked by the Great Firewall. This wouldn’t be an issue if widgets.js was fetched asynchronously, but sadly a peek at the HTML shows that’s not the case:

<a href="...">评论</a>
&nbsp;| &nbsp;
<span class="social-counters">
<span class="retweet">
<a href="http://twitter.com/share" class="twitter-share-button"
   data-count="horizontal"
   data-url="http://radar.oreilly.com/2011/12/four-short-links-6-december-20-1.html"
   data-text="Four short links: 6 December 2011" data-via="radar"
   data-related="oreillymedia:oreilly.com">鸣叫</a>
<script src="http://platform.twitter.com/widgets.js"
   type="text/javascript"></script>
</span>

<a href="...">Comment</a>
&nbsp;|&nbsp;
<span class="social-counters">
<span class="retweet">
<a href="http://twitter.com/share" class="twitter-share-button"
   data-count="horizontal"
   data-url="http://radar.oreilly.com/2011/12/four-short-links-6-december-20-1.html"
   data-text="Four short links: 6 December 2011" data-via="radar"
   data-related="oreillymedia:oreilly.com">Tweet</a>
<script src="http://platform.twitter.com/widgets.js"
   type="text/javascript"></script>
</span>

图 8-4。O'Reilly 雷达渲染被 Twitter 小部件阻止。

Figure 8-4. O’Reilly Radar rendering is blocked by Twitter widget.

从这些示例中可能得出的一个结论是，前端 SPOF 特定于 Twitter 和 Eyewonder 以及其他一些第三方小部件。遗憾的是，前端 SPOF 可能是由任何第三方小部件引起的，甚至是主网站自己的脚本、样式表或字体文件引起的。

One possible takeaway from these examples might be that frontend SPOF is specific to Twitter and eyewonder and a few other third-party widgets. Sadly, frontend SPOF can be caused by any third-party widget, and even from the main website’s own scripts, stylesheets, or font files.

这些示例的另一个可能的收获可能是避免被防火墙阻止的第三方小部件。但防火长城并不是导致前端 SPOF 的唯一原因，它只是使其更容易重现。任何需要很长时间才能返回的脚本、样式表或字体文件都有可能导致前端 SPOF。这种情况通常发生在出现中断或其他类型的故障时，例如服务器过载，HTTP 请求在服务器队列中滞留太久，导致浏览器超时。

Another possible takeaway from these examples might be to avoid third-party widgets that are blocked by the Great Firewall. But the Great Firewall isn’t the only cause of frontend SPOF—it just makes it easier to reproduce. Any script, stylesheet, or font file that takes a long time to return has the potential to cause frontend SPOF. This typically happens when there’s an outage or some other type of failure, such as an overloaded server where the HTTP request languishes in the server’s queue for so long the browser times out.

前端 SPOF 的真正原因是以阻塞方式加载脚本、样式表或字体文件。我的前端 SPOF ( http://www.stevesouders.com/blog/2010/06/01/frontend-spof/ ) 博客文章中的表格显示了这种情况发生的时间。实际上，网站所有者可以控制其网站是否容易受到前端 SPOF 的影响。那么网站所有者该怎么办呢？

The true cause of frontend SPOF is loading a script, stylesheet, or font file in a blocking manner. The table in my frontend SPOF (http://www.stevesouders.com/blog/2010/06/01/frontend-spof/) blog post shows when this happens. It’s really the website owner who controls whether or not their site is vulnerable to frontend SPOF. So what’s a website owner to do?

避免前端 SPOF 的最佳方法是异步加载脚本。许多流行的第三方小部件默认都会执行此操作，例如Google Analytics、Facebook和Meebo。Twitter 还为 O'Reilly Radar 应该使用的 Tweet 按钮提供了一个异步片段 ( https://dev.twitter.com/docs/tweet-button )。如果您使用的小部件不提供异步版本，您可以尝试 Stoyan 的社交按钮 BFF ( http://www.phpied.com/social-button-bffs/ ) 异步模式。

The best way to avoid frontend SPOF is to load scripts asynchronously. Many popular third-party widgets do this by default, such as Google Analytics, Facebook, and Meebo. Twitter also has an async snippet (https://dev.twitter.com/docs/tweet-button) for the Tweet button that O’Reilly Radar should use. If the widgets you use don’t offer an async version you can try Stoyan’s Social button BFFs (http://www.phpied.com/social-button-bffs/) async pattern.

另一个解决方案是将您的小部件包装在 iframe 中。这并不总是可行，但在上面的两个示例中，小部件最终在 iframe 中提供服务。从一开始就将它们放入 iframe 中可以避免前端 SPOF 问题。

Another solution is to wrap your widgets in an iframe. This isn’t always possible, but in two of the examples above the widget is eventually served in an iframe. Putting them in an iframe from the start would have avoided the frontend SPOF problems.

为了简洁起见，我重点关注脚本的解决方案。字体文件的解决方案可以在我的@font-face和性能（ http://www.stevesouders.com/blog/2009/10/13/font-face-and-performance/）博客文章中找到。我不知道有多少关于异步加载样式表的研究。导致过多的回流和 FOUC ( http://bluerobot.com/web/css/fouc.asp/ ) 是需要解决的问题。

For the sake of brevity I’ve focused on solutions for scripts. Solutions for font files can be found in my @font-face and performance (http://www.stevesouders.com/blog/2009/10/13/font-face-and-performance/) blog post. I’m not aware of much research on loading stylesheets asynchronously. Causing too many reflows and FOUC (http://bluerobot.com/web/css/fouc.asp/) are concerns that need to be addressed.

Business Insider、CNET 和 O'Reilly Radar 都有来自中国的访问者，但其页面的构建方式却带来了糟糕的用户体验，大部分（如果不是全部）页面被屏蔽超过一分钟。这不是 P2 前端 JavaScript 问题。这是一次停电。如果这些网站的后端服务器花了 1 分钟才发回响应，那么您可以打赌 Business Insider、CNET 和 O'Reilly 的 DevOps 团队不会睡觉，直到问题得到解决。那么为什么人们对前端 SPOF 的关注如此之少呢？

Business Insider, CNET, and O’Reilly Radar all have visitors from China, and yet the way their pages are constructed delivers a bad user experience where most if not all of the page is blocked for more than a minute. This isn’t a P2 frontend JavaScript issue. This is an outage. If the backend servers for these websites took 1 minute to send back a response, you can bet the DevOps teams at Business Insider, CNET, and O’Reilly wouldn’t sleep until the problem was fixed. So why is there so little concern about frontend SPOF?

前端单点故障并没有引起太多关注——考虑到它很容易导致网站瘫痪，它绝对没有得到应有的关注。原因之一是很难诊断。如果服务器响应时间超过 60 秒，许多监视器就会开始关闭。由于所有这些活动都在后端，因此更容易隔离原因。当客户端页面加载时间超过 60 秒时，寻呼机是否不会关闭？这很难相信，但也许情况确实如此。

Frontend SPOF doesn’t get much attention—it definitely doesn’t get the attention it deserves given how easily it can bring down a website. One reason is it’s hard to diagnose. There are a lot of monitors that will start going off if a server response time exceeds 60 seconds. And since all that activity is on the backend it’s easier to isolate the cause. Is it that pagers don’t go off when clientside page load times exceed 60 seconds? That’s hard to believe, but perhaps that’s the case.

也许这是跟踪页面加载时间的方式。如果您查看的是全球中位数甚至平均值，并且中国不是主要受众，那么当前端发生 SPOF 时，您的页面加载时间统计数据可能不会超过警报级别。或者，页面加载时间可能主要使用综合测试来跟踪，并且这些用户代理不会受到诸如防火墙之类的现实世界问题的影响。

Perhaps it’s the way page load times are tracked. If you’re looking at worldwide medians, or even averages, and China isn’t a major audience, your page load time stats might not exceed alert levels when frontend SPOF happens. Or maybe page load times are mostly tracked using synthetic testing, and those user agents aren’t subjected to real world issues like the Great Firewall.

网站所有者可以做的一件事是忽略前端 SPOF，直到它由未来的某些中断触发。快速计算表明这是一个可怕的选择。如果第三方小部件的正常运行时间为 99.99%，并且网站有五个非异步小部件，则前端 SPOF 的概率为 0.05%。如果我们将正常运行时间降低到 99.9%，则前端 SPOF 的概率就会上升到 0.5%。五个小部件可能很高，但请记住“第三方小部件”包括广告和指标。另外，网站自身的资源也会导致前端SPOF，从而导致这个数字更高。目前，网站平均包含 14 个脚本 ( http://httparchive.org/trends.php#bytesJS&reqJS )，如果未异步加载，其中任何一个脚本都可能导致前端 SPOF。

One thing website owners can do is ignore frontend SPOF until it’s triggered by some future outage. A quick calculation shows this is a scary choice. If a third-party widget has a 99.99% uptime and a website has five widgets that aren’t async, the probability of frontend SPOF is 0.05%. If we drop uptime to 99.9%, the probability of frontend SPOF climbs to 0.5%. Five widgets might be high, but remember that “third-party widget” includes ads and metrics. Also, the website’s own resources can cause frontend SPOF which brings the number even higher. The average website today contains 14 scripts (http://httparchive.org/trends.php#bytesJS&reqJS) any of which could cause frontend SPOF if they’re not loaded async.

前端单点故障是一个需要更多关注的现实问题。网站所有者应该使用异步代码片段和模式，监控真实的用户页面加载时间，并关注平均值以外的 95% 和标准偏差。执行这些操作将减轻用户遭受可怕的空白页的风险。链条的强度取决于其最薄弱的一环。您网站最薄弱的链接是什么？人们非常关注后端弹性。我敢打赌你最薄弱的环节是在前端。

Frontend SPOF is a real problem that needs more attention. Website owners should use async snippets and patterns, monitor real user page load times, and look beyond averages to 95th percentiles and standard deviations. Doing these things will mitigate the risk of subjecting users to the dreaded blank white page. A chain is only as strong as its weakest link. What’s your website’s weakest link? There’s a lot of focus on backend resiliency. I’ll wager your weakest link is on the frontend.

是时候开始认真购物了，让我们看看主要的移动零售玩家之一。从妈妈这个环游世界的旅行者开始，我想一套新的行李箱会很受欢迎。这里有很多选择——现在她最喜欢什么颜色？我有很多时间思考这个问题，因为这家零售商的 iPhone 应用程序需要相当长的时间才能加载。对 HTTP 瀑布的检查揭示了一条长长的资源菊花链，相互阻塞，持续 7.5 秒。请注意，在这种情况下，图像会阻止并行下载，这通常不会在 Web 应用程序中看到（图 10-1）。

Time to start some serious shopping, so let’s look at one of the major mobile retail players. Starting with Mom, the world traveller, I thought a new luggage set would be appreciated. Lots of choices here—now what’s her favorite color? I had lots of time to ponder this question, because this retailer’s iPhone app takes quite a while to load. Examination of the HTTP waterfall reveals a long daisy chain of resources blocking each other, lasting for 7.5 seconds. Notice that in this case, images are blocking parallel downloads, which is something you won’t typically see in a web app (Figure 10-1).

图 10-1。阻止下载

Figure 10-1. Blocking downloads

虽然 Web 开发人员可以通过一些简单的调整来启用并行下载，并信任浏览器制造商，但应由本机应用程序开发人员提出最佳的并发下载方案。我们的研究表明，即使在移动网络上，您也可以通过使用最多四个并行下载来获得性能提升，并且高级用户可以切换到 HTTP 管道来获得另一次速度提升。

While web developers can enable parallel downloads with a few simple tweaks and put their trust in browser makers, it’s up to the native app developer to come up with the optimal concurrent download scheme. Our research shows that even on mobile networks you can obtain a performance gain by using up to four parallel downloads, and advanced users can switch to HTTP pipelining to acquire another speed boost.

在图 10-1的瀑布中，您可能会注意到第一个资源services.xml长 81KB，并且需要超过一秒的时间才能通过网络获取（阻止其后面的任何其他资源）。在那一秒中，仅下载文件就花费了 812 毫秒。查看响应标头可以发现它是未压缩发送的。如果经过压缩，其重量仅为 6KB，响应时间至少可节省半秒。显然，它不是使用此应用程序发送未压缩的唯一资源（图 10-2）。

In the waterfall in Figure 10-1, you may notice that the first resource, services.xml is 81KB long and takes more than a second to fetch over the network (blocking any other resources following it). Of that second, 812ms are spent just downloading the file. Looking at the response headers one can see that it was sent uncompressed. If it were compressed, it would have weighted only 6KB, saving at least half a second in response time. Obviously, it’s not the only resource sent uncompressed using this app (Figure 10-2).

图 10-2。未压缩的资源

Figure 10-2. Uncompressed resources

这应该是理所当然的事情，但我们在许多 Android 和 iPhone 应用程序中观察到了这种性能反模式，值得指出。在实现本机应用程序时，开发人员有责任实现基本的缓存机制。仅设置 http 响应的缓存标头通常是不够的。以下是我在一家以手工制品闻名的电子商务网站的 iPhone 应用程序中寻找婴儿礼物时发生的情况（图 10-3）。

This should be a no brainer, but we have observed this performance anti-pattern in so many Android and iPhone apps that it’s worth pointing out. When implementing a native app, it’s the developer’s responsibility to implement a basic caching mechanism. Just setting the caching-headers of http responses is usually not enough. Here’s what happened when I was looking for a baby gift using the iPhone app of an e-commerce site known for its handmade items (Figure 10-3).

图 10-3。重复图像

Figure 10-3. Duplicate images

可爱的宝贝，但同一张图像被下载了三次，这对于许多其他也被多次下载的图像来说是典型的。此外，某些图像在同一 TCP 会话中下载了多个实例。创建一个基本的缓存层（只要应用程序运行就将元素缓存在内存中）并不复杂。它极大地提高了绩效并凸显了您的专业水平。

Cute baby, but the same image was downloaded three times, and this was typical for many other images that were also downloaded multiple times. Moreover, some images downloaded more than one instance in the same TCP session. Creating a basic caching layer, one that caches elements in memory as long as the application is running, is not that complicated. It greatly improves performance and highlights your professionalism.

厌倦了寻找通常的圣诞礼物，我启动了一家著名内衣零售商的应用程序，寻找，嗯，袜子来放入我女朋友的圣诞袜中。虽然我和其他人一样喜欢看 Adriana Lima，但下载她和其他 VS 模特的大图片实际上是相当痛苦的。令人惊讶的是，虽然我使用的是 iPhone，但我同时获得了 iPhone 和 iPad 版本的图像。iPad 图像显然没有针对我的小屏幕进行优化，浪费了半兆字节的流量。虽然这在有线网络上可能没问题，但在移动设备上却令人恼火（图 10-4）。

Tired of looking for the usual Christmas presents, I launched a famous lingerie retailer’s app, looking for, hmmm, stockings to put in my girlfriend’s Christmas stocking. Though I enjoy looking at Adriana Lima as much as the next guy, downloading huge images of her and the other VS models was actually quite painful. Surprisingly, although I was using an iPhone, I was getting both iPhone and iPad versions of the images. The iPad images were obviously not optimized for my small screen, and amounted to half a megabyte of wasted traffic. Although this might be OK over a wired network, it’s exasperating on a mobile (Figure 10-4).

图 10-4。iPad 版本的重复图像传送到 iPhone

Figure 10-4. Duplicate images with iPad versions served to iPhone

在过去的一年里，我们遇到了许多表现出类似性能失礼的应用程序。嘻哈飞行搜索应用 Hipmunk 下载了一个大数据文件（http://www.shunra.com/shunrablog/index.php/2011/03/21/being-slow-is-not-hip/）（后 650KB）压缩），将整个搜索结果包含在一个块中。最好将该文件拆分为几个较小的文件，其中一些文件可以异步下载。其他应用程序下载许多非常小的文件，可以轻松地将这些文件组合成更少的大文件，以避免由于移动网络的高延迟而造成的性能损失。

During the past year we have encountered many applications that exhibit similar performance faux-pas. Hipmunk, the hip flight search application, downloaded a big data file (http://www.shunra.com/shunrablog/index.php/2011/03/21/being-slow-is-not-hip/) (650KB after compression), containing the entire search results in one chunk. It would have been better to split that file into several smaller files, some of which could be downloaded asynchronously. Other applications download many very small files that could be easily combined into fewer larger files to circumvent a performance hit due to the high latency in mobile networks.

这只是本机移动应用程序性能最佳实践的一个简短示例，表明性能良好的本机应用程序和网站的一些原则并没有那么不同。消除不必要的下载（就字节数和请求数而言），并通过利用并行化和异步下载来管理其余部分，以充分利用网络。在网站上，您可以将许多任务交给浏览器，而在本机应用程序中，这主要取决于您。性能调整的空间要大得多，但出错的空间也更大。因此，如果有一个重要的要点，那就是始终尽早测试您的应用程序，永远不要让性能碰运气。

This is just a short sample of performance best-practices for native mobile apps, indicating that some of the principals of well-performing native apps and websites are not that different. Eliminate unnecessary downloads (with respect to both the number of bytes and the number of requests), and manage the rest to make good use of the network by leveraging parallelization and asynchronous downloads. While with web sites you relegate many of those tasks to the browser, with native apps it’s mostly up to you. The room for performance tweaks is much larger, but so is the room for mistakes. Thus, if there’s one important takeaway, it’s to always test your apps early and never leave performance to chance.

从性能角度来看，这是一个有趣的挑战，因为我使用的代码越少，最终图像就越小，并且执行速度越快（渲染时间）。我的目标是实现一种通用的解决方案，以便在网络上广泛使用。除了性能之外，作为一名前端工程师，我还对 CSS3 如何帮助解决这个问题（可能是跨浏览器）以及所施加的限制感兴趣。我使用 Chrome 进行开发，所以我的第一个目标是首先在该浏览器上实现这一点，然后再使其跨浏览器兼容。渲染时间的基准测试也很容易，这是我在谈论 CSS3 背景渐变、边框半径、变换等时最关心的问题。

It was an interesting challenge from performance perspective since the less code I used, the smaller the final image would be and the faster it would perform (rendering time). My goal was to achieve a one-size-fits all solution to be used in the wild on the Web. Besides performance, as a front end engineer, I was also interested in how CSS3 could help solve this issue (cross-browser possibly) and the limitations imposed. I use Chrome for development, so my first goal was to make it happen for that browser first before making it cross-browser compatible. It was also easy to benchmark the rendering time, which was my main point of concern when talking about CSS3 background gradients, border radius, transformation, etc.

将 JSFiddle ( http://jsfiddle.net/ ) 作为我的游乐场确实很有帮助，因为这是一项反复试验的任务，而且我可以轻松跟踪版本并共享。Chrome 开发者工具：元素样式 ( http://code.google.com/chrome/devtools/docs/elements-styles.html#styles_edit ) 也发挥了重要作用，让我可以即时测试我的更改。

Having JSFiddle (http://jsfiddle.net/) as my playground was really helpful because it was a trial-and-error task, plus I could keep track of versions and share so easily. Chrome Developer Tools: Element Styles (http://code.google.com/chrome/devtools/docs/elements-styles.html#styles_edit) also played an important role letting me test my changes on-the-fly.

我的 JSFiddle Playground 位于http://jsfiddle.net/marcelduran/g7KvW/6/，您可以在其中查看代码和最终图像结果。CSS 和 HTML 代码（这里没有 JavaScript）也列在本章末尾。

My JSFiddle playground is available at http://jsfiddle.net/marcelduran/g7KvW/6/, where you can see the code and final image result. The CSS and HTML code (no JavaScript here) is also listed at the end of the chapter.

fiddle 的“结果”选项卡上的三个图像从上到下依次为：原始（250 像素宽度）图像、250 像素宽度的纯 CSS3 图像和 50% 宽度的纯 CSS3 图像。如果您在 Chrome 中加载 fiddle，预计会获得更好的结果。JSFiddle 还允许您分叉代码并应用您自己的更改，所以请成为我的客人。

The three images on the Result tab of the fiddle are from top-down: original (250px width) image, pure CSS3 with 250px width, and pure CSS3 with 50% width. If you load the fiddle in Chrome, you’re expected to get better results. JSFiddle also allows you to fork the code and apply your own changes, so be my guest.

使用 21 个 DOM 元素（按<style>块计算为 22 个），并通过使用不均匀 border-radius的几何图形、背景渐变使其闪亮、圆润且更真实，以及一些变换旋转足以最终获得没有红针的 YSlow 速度计徽标。我的第一次尝试是使用 DOM 元素边框来实现一个尖三角形（http://jonrohan.me/guide/css/creating-triangles-in-css/），它工作得很好，但不幸的是，由于百分比值，它没有缩放不允许（http://www.w3.org/TR/CSS2/box.html#value-def-border-width）border-width。此外，背景渐变也不适用于边框，使其不像原始图像那样闪亮。当我碰壁时，我联系了我的前同事蒂埃里·科布伦茨 (Thierry Koblentz) ( http://twitter.com/thierrykoblentz )，他来救援了。他不仅把 CSS 当早餐吃，而且总是准备迎接 CSS 的挑战。令人印象深刻的是，他想出了一个非常好的解决方案，使用旋转移位的 DIV 隐藏不需要的部分 overflow:hidden，这使我能够通过背景渐变使其闪亮。作为一个优点，他还包括一个很好的过渡，可以在悬停时将针平滑地动画到最大值，这样的功能在常规 PNG/JPG 图像中不可用。

With 21 DOM elements (22 counting the <style> block) and by using uneven border-radius for geometries, background gradients to make it shiny, rounded, and more realistic, and some transform rotations were enough to finally get the YSlow speedometer logo without the red needle. My first attempt was to use DOM element borders to achieve a pointy triangle (http://jonrohan.me/guide/css/creating-triangles-in-css/) which works fine but unfortunately, it did not scale due to percentage values not being allowed (http://www.w3.org/TR/CSS2/box.html#value-def-border-width) on border-width. Also background gradients do not apply to borders either, making it not shiny as in the original image. When I hit this wall, I pinged my former co-worker Thierry Koblentz (http://twitter.com/thierrykoblentz), and he came to the rescue. He eats CSS not only for breakfast and is always up for CSS challenges. It was impressive, he came up with a very nice solution using rotated displaced DIVs hiding the undesired parts with overflow:hidden, which allowed me to make it shiny through background gradient. As a plus, he also included a nice transition that smoothly animates the needle to the max value when hovering, such feature is not available in regular PNG/JPG images.

在我实现了 Chrome 的目标之后，基本上使用 CSS3 的 W3C 规范和一些-webkit-前缀，是时候攻击其他浏览器了，所以我开始为 Internet Explorer添加其他供应商前缀，例如-moz-、-o-、 -ms-和。filter

After I reached my goal for Chrome, using basically W3C specification for CSS3 and a few -webkit- prefixes, it was time to attack the other browsers, so I started adding other vendors prefixes like -moz-, -o-, -ms-, and filter for Internet Explorer.

我对跨浏览器的结果非常失望，在花了一些时间试图找到一种方法来解决所有浏览器的问题而不增加 CSS 代码或添加更多 HTML 元素之后，我放弃了并扮演约翰列侬：“想象一下没有跨浏览器问题……”我想知道我们尊敬的表演日历策展人 ( http://twitter.com/stoyanstefanov ) 以前怎么没有想到过这样一首歌曲 ( http://www.youtube.com/watch?v= bPdkWJe9XH0 )。

I got very disappointed with the cross-browser results and after spending some time trying to figure out a way to fix things for all browsers without increasing the CSS code or adding more HTML elements, I gave up and played John Lennon: “Imagine there's no cross-browser issue…” I wonder how come our honorable Performance Calendar curator (http://twitter.com/stoyanstefanov) hasn't thought about such a song before (http://www.youtube.com/watch?v=bPdkWJe9XH0).

原始图像（PNG24）如图11-1所示。

The original image (PNG24) is shown in Figure 11-1.

图 11-1。PNG24 格式的原始 YSlow 徽标

Figure 11-1. original YSlow logo in PNG24 format

测试浏览器带注释的截图如图 11-2（非IE浏览器）和图11-3（不同IE版本）。这些图中的左列图像显示了使用特定于供应商的 CSS 时的结果，右列仅显示 W3C 有效的 CSS3。

The screenshots for the tested browsers with comments are shown in Figure 11-2 (non-IE browsers) and Figure 11-3 (different IE versions). The left column of images in those figures shows the result when using vendor-specific CSS and the right column is W3C-valid CSS3 only.

图 11-2。非 IE 浏览器中的结果

Figure 11-2. Results in non-IE browsers

图 11-3。IE 中的结果

Figure 11-3. Results in IE

有趣的是，仅限 W3C 的版本如何优雅地回退，这表明没有浏览器严格遵循规范，或者在撰写本文时规范尚未完全定义。即使不完全像原来的，除了一些例外，它们在某种程度上看起来都像一个速度计，除了呃，猜猜是谁？

Interesting how the W3C-only versions fall back gracefully, that shows no browser is strictly following specs or that the specs are not fully defined yet by the time of this writing. Even not fully resembling the original, with some exceptions, they all look like a speedometer gauge somehow, except er, guess who?

由于纯 CSS3 图像至少在 Chrome 上运行良好，我能够为设计师提供他们想要的东西，这足以让我开始我的性能基准测试。我知道有人可能会说，可以让它在具有更多 DOM 元素和/或更多 CSS 选择器/规则的其他浏览器上更好地工作，但这是一项耗时的任务，而且我在业余时间正在研究它，所以足够了CSS，让我们看看我们来这里的目的是什么。

With that pure CSS3 image working decently at least on Chrome, I was able to provide the designers what they were after and that was enough for me to start my performance benchmarking. I know one might argue it’s possible to make it work better on other browsers with more DOM elements and/or more CSS selectors/rules, but that was a time-consuming task and I was working on it during my spare time, so enough with CSS and let’s see what we are here for.

为了比较真实的图像文件（http://wh.yslow.org/css3-logo-images）与CSS3生成的图像文件（http://wh.yslow.org/css3-logo-payload），我创建了一个少数页面每页仅包含一张图像，或者是真实文件 URL 和数据 URI ( http://en.wikipedia.org/wiki/Data_URI_scheme ) ( ) 或 CSS3（同一页面中的&ltimg src="...">HTML + CSS 块）。<style>

In order to compare real image files (http://wh.yslow.org/css3-logo-images) versus CSS3-generated ones (http://wh.yslow.org/css3-logo-payload), I created a few pages containing only one image per page, either real files URL and data URI (http://en.wikipedia.org/wiki/Data_URI_scheme) (&ltimg src="...">) or CSS3 (HTML + CSS <style> block in the same page).

渲染

Rendering

在这些页面的底部添加一个小脚本 ( http://wh.yslow.org/css3-logo-renderingsessionStorage )，使用( https://developer.mozilla.org/)以 1 秒的间隔重新加载页面 100 次 en/DOM/Storage#sessionStorage）用于计数，并使用Chrome 开发者工具：记录页面活动的时间轴面板，我能够导出记录的数据（http://wh.yslow.org/css3-logo-logs）。然后使用NodeJS 脚本，我可以仅提取和过滤与渲染活动相关的时间，清理样本的顶部和底部 5% 以删除一些噪声数据，然后获取平均值（http://wh.yslow . org/css3-logo-结果）以毫秒为单位（图11-4）。

Adding a small script at the bottom of these pages (http://wh.yslow.org/css3-logo-rendering) that reloads the page 100 times with 1 second interval, using sessionStorage (https://developer.mozilla.org/en/DOM/Storage#sessionStorage) for counting and with Chrome Developer Tools: Timeline Panel recording the page activity, I was able to export the logged data (http://wh.yslow.org/css3-logo-logs). Then with a NodeJS script, I could extract and filter only the timing related to the rendering activity, cleaning the top and bottom 5% of the sample to remove some noisy data, and then getting the average (http://wh.yslow.org/css3-logo-results) in milliseconds (Figure 11-4).

图 11-4。时间轴面板

Figure 11-4. Timeline panel

对YSlow标志图像对比版本的分析如图11-5的表格所示，得出 图11-6的图表。该图表的数据可从 http://wh.yslow.org/css3-logo-data获取。

Analysis of the compared versions of YSlow logo image is shown in the table on Figure 11-5, which leads to the chart on Figure 11-6. The data for the chart is available at http://wh.yslow.org/css3-logo-data.

图 11-5。YSlow标志图版本对比

Figure 11-5. The compared versions of YSlow logo image

图 11-6。有效负载与渲染

Figure 11-6. Payload versus Rendering

与常规图像（无论是 URL 还是数据 URI）相比，CSS3 生成的图像可以获得更小的有效负载。在这个 YSlow 徽标示例中，W3C 标准 CSS3 大约比 PNG24 图像版本小 34 倍。相同图像类型的数据 URI 版本在压缩后具有大致相同的有效负载。它们仅增加了几个字节，有趣的是，本例中 JPG 的内联版本比常规 JPG 图像文件稍小。

CSS3-generated images can achieve smaller payloads compared to regular images either URL or data URI ones. In this YSlow logo example, the W3C standard CSS3 is roughly 34 times smaller than PNG24 image version. Data URI versions of the same image type have around the same payload after being compressed. They get increased a few bytes only, interesting in this case that the inline version of JPG is slightly smaller than the regular JPG image file.

另一方面，CSS3 生成的图像渲染时间比常规图像更差，比 PNG24 版本慢约 6.5 倍。与常规图像文件版本相比，内联版本的渲染时间延长了一倍多。CSS3 W3C 标准版本的渲染速度比-webkit-具有所有浏览器供应商前缀的渲染速度快 2.5 倍。这并不一定意味着它真的更快，因为根据上面的屏幕截图结果，它们都没有触发所有 CSS 规则来根据原始版本正确渲染徽标。

On the other hand, CSS3-generated images rendering time is worse than regular images, being around 6.5 times slower than the PNG24 version. The inline versions more than double the rendering time when compared to their regular image file versions. The CSS3 W3C standard version rendering performed 2.5 times faster than -webkit- or the one with all browser vendors prefixes. This doesn’t necessarily mean it’s really faster because per the screenshots results above, none of them triggered all the CSS rules to render the logo properly according to the original version.

这些渲染时间是通过在页面上显示静态图像来测量的，没有任何悬停用户交互来使 CSS3 版本上的仪表指针动画化。在允许用户在视口上隐藏和显示或拖放图像从而触发多次重绘、回流和重新样式的情况下，这些数字可能会增加 ( http://www.phpied.com /rendering-repaint-reflowrelayout-restyle/）在这些 DOM 元素上。

These rendering times were measured just by displaying the static images on the page without any hovering user interaction that animates the gauge needle on CSS3 versions. These numbers would likely to be increased in the case-scenario where users are allowed to hide-and-show or drag-and-drop images over the viewport triggering several repaint, reflow, and restyle (http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/) on these DOM elements.

从质量角度比较，带有所有前缀的 CSS3 或 -webkit-在 Chrome 上与 PNG24 版本相当，两者都有透明背景且没有像素化。CSS3 小了 34 倍，慢了 6.5 倍（以毫秒为单位），并且具有针对不同大小保持相同有效负载的优点，而 PNG 在从原始源（PSD 可用时）调整大小时会增加以避免质量损失，但用户无法在不截图的情况下将 CSS3 保存为图像。

Comparing apples-to-apples quality-wise, CSS3 with all prefixes or -webkit- on Chrome are comparable to the PNG24 version, both have transparent background and no pixelation. CSS3 is 34 times smaller, 6.5 times slower (in order of milliseconds) and has the advantage of keeping the same payload for different sizes, while PNG would increase when resized from the original source (PSD when available) to avoid quality loss, however users are not able to save CSS3 as an image without taking screenshots.

并非如此，希望在不久的将来我们能够摆脱浏览器供应商的特定前缀，并拥有一个在所有浏览器中都同样有效的通用 CSS 解决方案。但即使我们做到了这一点，手动使用 DOM 元素和样式从头开始创建图像也是一项非常耗时的任务（SVG 就是为此设计的）。此类任务非常需要一种辅助绘图的插画工具，人们可以拖动贝塞尔曲线（http://en.wikipedia.org/wiki/B%C3%A9zier_curve），调整控制点以获得对应的点CSS3border-radius正确塑造几何线条的指令。

Not really, hopefully in the near future we'll get rid of browser vendors’ specific prefixes and have a one-size-fits-all CSS solution that works equally in all browsers. But even when we get there, it's a very time-consuming task to create images from scratch, using DOM elements and styles manually (SVG is designed for this). An illustrator tool to aid drawing is in high demand for such task where one could drag over Bézier curves (http://en.wikipedia.org/wiki/B%C3%A9zier_curve), adjusting the control points in order to get the correspondent directives to CSS3 border-radius shaping geometric lines properly.

您还可以在http://jsfiddle.net/marcelduran/g7KvW/6/上实时使用代码。

You can also play with the code live at http://jsfiddle.net/marcelduran/g7KvW/6/.

<img src="http://d.yimg.com/jc/ydn/speedometer.png">
<div class="ys" style="width:250px">
    <div class="a">
        <div class="b">
            <div class="c">
                <div class="d">
                    <div class="e">
                        <div class="f"></div>
                        <div class="g"></div>
                        <div class="t t1"></div>
                        <div class="t t2"></div>
                        <div class="t t3"></div>
                        <div class="t t4"></div>
                        <div class="t t5"></div>
                        <div class="t t6"></div>
                        <div class="t t7"></div>
                        <div class="p">
                            <div class="pw">
                                <div class="pi">
                                    <div class="pl"></div>
                                </div>
                                <div class="pi">
                                    <div class="pr"></div>
                                </div>
                            </div>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

<div class="ys" style="width:50%">
    <div class="a">
        <div class="b">
            <div class="c">
                <div class="d">
                    <div class="e">
                        <div class="f"></div>
                        <div class="g"></div>
                        <div class="t t1"></div>
                        <div class="t t2"></div>
                        <div class="t t3"></div>
                        <div class="t t4"></div>
                        <div class="t t5"></div>
                        <div class="t t6"></div>
                        <div class="t t7"></div>
                        <div class="p">
                            <div class="pw">
                                <div class="pi">
                                    <div class="pl"></div>
                                </div>
                                <div class="pi">
                                    <div class="pr"></div>
                                </div>
                            </div>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

<img src="http://d.yimg.com/jc/ydn/speedometer.png">
<div class="ys" style="width:250px">
    <div class="a">
        <div class="b">
            <div class="c">
                <div class="d">
                    <div class="e">
                        <div class="f"></div>
                        <div class="g"></div>
                        <div class="t t1"></div>
                        <div class="t t2"></div>
                        <div class="t t3"></div>
                        <div class="t t4"></div>
                        <div class="t t5"></div>
                        <div class="t t6"></div>
                        <div class="t t7"></div>
                        <div class="p">
                            <div class="pw">
                                <div class="pi">
                                    <div class="pl"></div>
                                </div>
                                <div class="pi">
                                    <div class="pr"></div>
                                </div>
                            </div>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

<div class="ys" style="width:50%">
    <div class="a">
        <div class="b">
            <div class="c">
                <div class="d">
                    <div class="e">
                        <div class="f"></div>
                        <div class="g"></div>
                        <div class="t t1"></div>
                        <div class="t t2"></div>
                        <div class="t t3"></div>
                        <div class="t t4"></div>
                        <div class="t t5"></div>
                        <div class="t t6"></div>
                        <div class="t t7"></div>
                        <div class="p">
                            <div class="pw">
                                <div class="pi">
                                    <div class="pl"></div>
                                </div>
                                <div class="pi">
                                    <div class="pr"></div>
                                </div>
                            </div>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

/* borders and background */
.ys .a {padding:1.5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #b0b4b7;
    background: -moz-linear-gradient(left, #b0b4b7 8%, #3f3f40 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#b0b4b7), 
     color-stop(54%,#3f3f40));
    background: -webkit-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    background: -o-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    background: -ms-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#b0b4b7',
     endColorstr='#3f3f40',GradientType=1);
    background: linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
}

.ys .b {padding:5% 5% 0 5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #dadadc;
    background: -moz-linear-gradient(left, #dadadc 8%, #3a3a3c 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#dadadc), 
     color-stop(54%,#3a3a3c));
    background: -webkit-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    background: -o-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    background: -ms-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#dadadc', 
     endColorstr='#3a3a3c',GradientType=1 );
    background: linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
}

.ys .c {padding:2.5% 2.5% 0 2.5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #e1e4e5;
    background: -moz-linear-gradient(left, #e1e4e5 8%, #010204 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#e1e4e5), 
     color-stop(54%,#010204));
    background: -webkit-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    background: -o-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    background: -ms-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#e1e4e5', 
     endColorstr='#010204',GradientType=1 );
    background: linear-gradient(left, #e1e4e5 8%,#010204 54%);
}

.ys .d {padding:2%; background-color:#0c1c48;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
}

.ys .e {padding:58% 5% 0 5%; position:relative; overflow:hidden;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #394d97;
    background: -moz-linear-gradient(left, #394d97 8%, #282963 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#394d97), 
     color-stop(54%,#282963));
    background: -webkit-linear-gradient(left, #394d97 8%,#282963 54%);
    background: -o-linear-gradient(left, #394d97 8%,#282963 54%);
    background: -ms-linear-gradient(left, #394d97 8%,#282963 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#394d97', 
     endColorstr='#282963',GradientType=1 );
    background: linear-gradient(left, #394d97 8%,#282963 54%);
}

/* glare */
.ys .f {padding:50% 56%; position:absolute; top:11%; left:0;
    -moz-border-radius:166% 133% 0 0 / 166% 139% 0 0;
    -webkit-border-top-left-radius:166em 166em;
    -webkit-border-top-right-radius:133em 139em;
    border-radius:166% 133% 0 0 / 166% 139% 0 0;
    background: #2c3e90;
    background: -moz-linear-gradient(left, #2c3e90 8%, #120744 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#2c3e90), 
     color-stop(54%,#120744));
    background: -webkit-linear-gradient(left, #2c3e90 8%,#120744 54%);
    background: -o-linear-gradient(left, #2c3e90 8%,#120744 54%);
    background: -ms-linear-gradient(left, #2c3e90 8%,#120744 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#2c3e90', 
     endColorstr='#120744',GradientType=1 );
    background: linear-gradient(left, #2c3e90 8%,#120744 54%);
}

/* base */
.ys .g {padding:50% 74%; position:absolute; bottom:-135%; left:-16%;
    -moz-border-radius:100%;
    -webkit-border-radius:1000em;
    border-radius:100%;
    background: #99c1e2;
    background: -moz-linear-gradient(top, #99c1e2 1%, #7aaed9 3%, #2f6bb0 12%);
    background: -webkit-gradient(linear, left top, left bottom, color-stop(1%,#99c1e2), 
     color-stop(3%,#7aaed9), color-stop(12%,#2f6bb0));
    background: -webkit-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    background: -o-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    background: -ms-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#99c1e2', 
     endColorstr='#2f6bb0',GradientType=0 );
    background: linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
}

/* ticks */
.ys .t {width:14%; height:6%; background-color:#e7e8e9; position:absolute;
    -moz-border-radius:30% / 100%;
    -webkit-border-radius:1000em;
    border-radius:30% / 100%;
}
.ys .t1 {left:7%; bottom:18%;}
.ys .t2 {left:11%; bottom:47%;
    -webkit-transform:rotate(30deg);
    -moz-transform:rotate(30deg);
    -o-transform:rotate(30deg);
    -ms-transform:rotate(30deg);
    transform:rotate(30deg);
}
.ys .t3 {left:24%; bottom:70%;
    -webkit-transform:rotate(60deg);
    -moz-transform:rotate(60deg);
    -o-transform:rotate(60deg);
    -ms-transform:rotate(60deg);
    transform:rotate(60deg);
}
.ys .t4 {left:44%; top:16%;
    -webkit-transform:rotate(90deg);
    -moz-transform:rotate(90deg);
    -o-transform:rotate(90deg);
    -ms-transform:rotate(90deg);
    transform:rotate(90deg);
}
.ys .t5 {right:24%; bottom:70%;
    -webkit-transform:rotate(-60deg);
    -moz-transform:rotate(-60deg);
    -o-transform:rotate(-60deg);
    -ms-transform:rotate(-60deg);
    transform:rotate(-60deg);
}
.ys .t6 {right:11%; bottom:47%;
    -webkit-transform:rotate(-30deg);
    -moz-transform:rotate(-30deg);
    -o-transform:rotate(-30deg);
    -ms-transform:rotate(-30deg);
    transform:rotate(-30deg);
}
.ys .t7 {right:7%; bottom:18%;}

/* pointer by @thierrykoblentz */
.ys .p {padding-bottom:52%; width:11%; position:absolute; left:50%; bottom:20%; 
 margin-left:-5%;
    -webkit-transform:rotate(20deg);
    -moz-transform:rotate(20deg);
    -o-transform:rotate(20deg);
    -ms-transform:rotate(20deg);
    transform:rotate(20deg);
    -webkit-transform-origin:bottom;
    -webkit-transition:all 200ms cubic-bezier(0.200, 0.000, 1.000, 0.360);
}
.ys:hover .p {
    -webkit-transform:rotate(90deg);
    -moz-transform:rotate(90deg);
    -o-transform:rotate(90deg);
    -ms-transform:rotate(90deg);
    transform:rotate(90deg);
}
.ys .pw {position:absolute; top:0; right:0; bottom:0; left:0;}
.ys .pw > :first-child {border-right:1px solid transparent; margin-right:-2px;}
.ys .p::after {content:""; position:absolute; width:97%; padding-bottom:92%; top:88%; 
 z-index:1;
    -moz-border-radius:100%;
    -webkit-border-radius:1000em;
    border-radius:100%;
    background: #ef4d58;
    background: -moz-linear-gradient(left, #ef4d58 10%, #ce1f2b 20%);
    background: -webkit-gradient(linear, left top, right top, color-stop(10%,#ef4d58), 
     color-stop(20%,#ce1f2b));
    background: -webkit-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -o-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -ms-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ef4d58', 
     endColorstr='#ce1f2b',GradientType=1);
    background: linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
}
.ys .pi {width:50%; height:100%; overflow:hidden; position:relative; float:left;}
.ys .pl, .ys .pr {position:absolute; width:200%; height:120%; left:50%;
    -webkit-transform:rotate(10deg);
    -moz-transform:rotate(10deg);
    -o-transform:rotate(10deg);
    -ms-transform:rotate(10deg);
    transform:rotate(10deg);
    background: #ef4d58;
    background: -moz-linear-gradient(left, #ef4d58 10%, #ce1f2b 20%);
    background: -webkit-gradient(linear, left top, right top, color-stop(10%,#ef4d58), 
     color-stop(20%,#ce1f2b));
    background: -webkit-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -o-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -ms-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ef4d58', 
     endColorstr='#ce1f2b',GradientType=1 );
    background: linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
}
.ys .pr {right:50%; left:auto;
    -webkit-transform:rotate(-10deg);
    -moz-transform:rotate(-10deg);
    -o-transform:rotate(-10deg);
    -ms-transform:rotate(-10deg);
    transform:rotate(-10deg);
}

/* borders and background */
.ys .a {padding:1.5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #b0b4b7;
    background: -moz-linear-gradient(left, #b0b4b7 8%, #3f3f40 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#b0b4b7), 
     color-stop(54%,#3f3f40));
    background: -webkit-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    background: -o-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    background: -ms-linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#b0b4b7',
     endColorstr='#3f3f40',GradientType=1);
    background: linear-gradient(left, #b0b4b7 8%,#3f3f40 54%);
}

.ys .b {padding:5% 5% 0 5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #dadadc;
    background: -moz-linear-gradient(left, #dadadc 8%, #3a3a3c 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#dadadc), 
     color-stop(54%,#3a3a3c));
    background: -webkit-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    background: -o-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    background: -ms-linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#dadadc', 
     endColorstr='#3a3a3c',GradientType=1 );
    background: linear-gradient(left, #dadadc 8%,#3a3a3c 54%);
}

.ys .c {padding:2.5% 2.5% 0 2.5%;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #e1e4e5;
    background: -moz-linear-gradient(left, #e1e4e5 8%, #010204 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#e1e4e5), 
     color-stop(54%,#010204));
    background: -webkit-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    background: -o-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    background: -ms-linear-gradient(left, #e1e4e5 8%,#010204 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#e1e4e5', 
     endColorstr='#010204',GradientType=1 );
    background: linear-gradient(left, #e1e4e5 8%,#010204 54%);
}

.ys .d {padding:2%; background-color:#0c1c48;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
}

.ys .e {padding:58% 5% 0 5%; position:relative; overflow:hidden;
    -moz-border-radius:100% 100% 0 0 / 166% 166% 0 0;
    -webkit-border-top-left-radius:1000em;
    -webkit-border-top-right-radius:1000em;
    border-radius:100% 100% 0 0 / 166% 166% 0 0;
    background: #394d97;
    background: -moz-linear-gradient(left, #394d97 8%, #282963 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#394d97), 
     color-stop(54%,#282963));
    background: -webkit-linear-gradient(left, #394d97 8%,#282963 54%);
    background: -o-linear-gradient(left, #394d97 8%,#282963 54%);
    background: -ms-linear-gradient(left, #394d97 8%,#282963 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#394d97', 
     endColorstr='#282963',GradientType=1 );
    background: linear-gradient(left, #394d97 8%,#282963 54%);
}

/* glare */
.ys .f {padding:50% 56%; position:absolute; top:11%; left:0;
    -moz-border-radius:166% 133% 0 0 / 166% 139% 0 0;
    -webkit-border-top-left-radius:166em 166em;
    -webkit-border-top-right-radius:133em 139em;
    border-radius:166% 133% 0 0 / 166% 139% 0 0;
    background: #2c3e90;
    background: -moz-linear-gradient(left, #2c3e90 8%, #120744 54%);
    background: -webkit-gradient(linear, left top, right top, color-stop(8%,#2c3e90), 
     color-stop(54%,#120744));
    background: -webkit-linear-gradient(left, #2c3e90 8%,#120744 54%);
    background: -o-linear-gradient(left, #2c3e90 8%,#120744 54%);
    background: -ms-linear-gradient(left, #2c3e90 8%,#120744 54%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#2c3e90', 
     endColorstr='#120744',GradientType=1 );
    background: linear-gradient(left, #2c3e90 8%,#120744 54%);
}

/* base */
.ys .g {padding:50% 74%; position:absolute; bottom:-135%; left:-16%;
    -moz-border-radius:100%;
    -webkit-border-radius:1000em;
    border-radius:100%;
    background: #99c1e2;
    background: -moz-linear-gradient(top, #99c1e2 1%, #7aaed9 3%, #2f6bb0 12%);
    background: -webkit-gradient(linear, left top, left bottom, color-stop(1%,#99c1e2), 
     color-stop(3%,#7aaed9), color-stop(12%,#2f6bb0));
    background: -webkit-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    background: -o-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    background: -ms-linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#99c1e2', 
     endColorstr='#2f6bb0',GradientType=0 );
    background: linear-gradient(top, #99c1e2 1%,#7aaed9 3%,#2f6bb0 12%);
}

/* ticks */
.ys .t {width:14%; height:6%; background-color:#e7e8e9; position:absolute;
    -moz-border-radius:30% / 100%;
    -webkit-border-radius:1000em;
    border-radius:30% / 100%;
}
.ys .t1 {left:7%; bottom:18%;}
.ys .t2 {left:11%; bottom:47%;
    -webkit-transform:rotate(30deg);
    -moz-transform:rotate(30deg);
    -o-transform:rotate(30deg);
    -ms-transform:rotate(30deg);
    transform:rotate(30deg);
}
.ys .t3 {left:24%; bottom:70%;
    -webkit-transform:rotate(60deg);
    -moz-transform:rotate(60deg);
    -o-transform:rotate(60deg);
    -ms-transform:rotate(60deg);
    transform:rotate(60deg);
}
.ys .t4 {left:44%; top:16%;
    -webkit-transform:rotate(90deg);
    -moz-transform:rotate(90deg);
    -o-transform:rotate(90deg);
    -ms-transform:rotate(90deg);
    transform:rotate(90deg);
}
.ys .t5 {right:24%; bottom:70%;
    -webkit-transform:rotate(-60deg);
    -moz-transform:rotate(-60deg);
    -o-transform:rotate(-60deg);
    -ms-transform:rotate(-60deg);
    transform:rotate(-60deg);
}
.ys .t6 {right:11%; bottom:47%;
    -webkit-transform:rotate(-30deg);
    -moz-transform:rotate(-30deg);
    -o-transform:rotate(-30deg);
    -ms-transform:rotate(-30deg);
    transform:rotate(-30deg);
}
.ys .t7 {right:7%; bottom:18%;}

/* pointer by @thierrykoblentz */
.ys .p {padding-bottom:52%; width:11%; position:absolute; left:50%; bottom:20%; 
 margin-left:-5%;
    -webkit-transform:rotate(20deg);
    -moz-transform:rotate(20deg);
    -o-transform:rotate(20deg);
    -ms-transform:rotate(20deg);
    transform:rotate(20deg);
    -webkit-transform-origin:bottom;
    -webkit-transition:all 200ms cubic-bezier(0.200, 0.000, 1.000, 0.360);
}
.ys:hover .p {
    -webkit-transform:rotate(90deg);
    -moz-transform:rotate(90deg);
    -o-transform:rotate(90deg);
    -ms-transform:rotate(90deg);
    transform:rotate(90deg);
}
.ys .pw {position:absolute; top:0; right:0; bottom:0; left:0;}
.ys .pw > :first-child {border-right:1px solid transparent; margin-right:-2px;}
.ys .p::after {content:""; position:absolute; width:97%; padding-bottom:92%; top:88%; 
 z-index:1;
    -moz-border-radius:100%;
    -webkit-border-radius:1000em;
    border-radius:100%;
    background: #ef4d58;
    background: -moz-linear-gradient(left, #ef4d58 10%, #ce1f2b 20%);
    background: -webkit-gradient(linear, left top, right top, color-stop(10%,#ef4d58), 
     color-stop(20%,#ce1f2b));
    background: -webkit-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -o-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -ms-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ef4d58', 
     endColorstr='#ce1f2b',GradientType=1);
    background: linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
}
.ys .pi {width:50%; height:100%; overflow:hidden; position:relative; float:left;}
.ys .pl, .ys .pr {position:absolute; width:200%; height:120%; left:50%;
    -webkit-transform:rotate(10deg);
    -moz-transform:rotate(10deg);
    -o-transform:rotate(10deg);
    -ms-transform:rotate(10deg);
    transform:rotate(10deg);
    background: #ef4d58;
    background: -moz-linear-gradient(left, #ef4d58 10%, #ce1f2b 20%);
    background: -webkit-gradient(linear, left top, right top, color-stop(10%,#ef4d58), 
     color-stop(20%,#ce1f2b));
    background: -webkit-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -o-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    background: -ms-linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
    filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ef4d58', 
     endColorstr='#ce1f2b',GradientType=1 );
    background: linear-gradient(left, #ef4d58 10%,#ce1f2b 20%);
}
.ys .pr {right:50%; left:auto;
    -webkit-transform:rotate(-10deg);
    -moz-transform:rotate(-10deg);
    -o-transform:rotate(-10deg);
    -ms-transform:rotate(-10deg);
    transform:rotate(-10deg);
}